Комментарии 115
А что мешает при утечке нормализовать емейлы, и тогда невозможно будет от кого произошёл слив.
Вот именно, фигня этот ваш плюс
Вопрос хороший, конечно, никто не мешает им почистить базу.
Но фишка в том, что почти все спамеры — дико ленивые ребята. Они гоняют гигантские сырые списки, и им просто лень заморачиваться с какой-то там «нормализацией». Главное быстро заспамить
И тут два варианта:
Спамер умный и почистил базу, ну окей, спам упадет в твой основной ящик. Ситуация ровно та же, как если бы ты не использовал тег. Ты ничего не потерял.
Спамер — лентяй, а он почти всегда лентяй и ты сразу видишь, кто слил твою почту.
Так что «плюс» в почте — это не защита от всех проблем, она сработает не на профи-взломщика, а на обычную массовку.
Но с другой стороны, если везде указывать плюс, то если пришло письмо без плюса, то потенциально это спам :)
Ну да))) Это и есть продвинутый уровень.
Основной ящик держишь только для своих и банков, а для всего остального мира - почту с "+"
В итоге всё, что прилетает на «голый» адрес без тега, с вероятностью 99% спам. По сути обратный фильтр.
Часто после оформления карты в банке спам и начинает лететь на почту/телефон
Так каждый банк теперь заодно ещё и маркетплейс, и страховая компания, и кофейня, и брокер, авиабилеты продаёт. Ну и ваш номер с почтой тоже всем сливает направо и налево, разумеется.
Это точно. Зарегался в том году в тинькоффе, так вот, ровно с тех времён на мой основной email Яндекс почты как из рога изобилия стал сыпаться спам от всевозможных mail@server.shop
А именно, спам поступает с info@caseycal.com
info@milenas.shop
info@casecas.shop
и только. Думаю всё разобраться, на кого замешаны домены, по идее, в reg.ru, хотя и не точно. Прикрыть бы эту лавочку..
Скрин типичного спама (благо почтовая программа автоматически кладёт это в папку Спам)
О! Точно так и мне сыпется. Думаю, адреса отправителя поддельные, у меня другие там.
При этом я сам у них не регистрировался, но был инцидент, когда пытались на меня ИП оформить и счёт там открыть, присылали ссылки, типа просто что-то проверить, а по факту там оставалось 1 действие до завершения регистрации. ИП не открыли, несколько раз я им звонил и писал и ругался, а вот через какое-то время понеслось с таким спамом.
Зачем для банков делать исключение?
и ты сразу видишь, кто слил твою почту.
И делаешь что?
Наверное в black list добавляешь с гордостью.
Не помню, когда последний раз видел спам в почте. Спамодав достаточно успешно его детектит.
Всё так. Я иногда залажу в спам, посмотреть что там новое разводилы придумали. Так так всё шаблонно - рандомный адрес отправки с какого-то крупного сервиса, в заголовке какая-то хрень типа "Предложение работы. Вас пригласили на интервью" и в теле абсолютно рандомная хрень из популярных слов, которая к заголовку даже отношения не имеет.
Интересно, зачем они вообще стараются? Очевидно что подобное не прокатит. Современный спамодав скорее зарежет по подозрению что-то ценное чем пропустит их высеры без фантазии.
вот именно, что ленивые и как правило не заморачиваются с такими мелочами, поэтому использовать всё же не совсем бесполезно. Ровно как и добавить пару запятых, что бы сломать базу паролей в чьём-то эксельчике
Лень мешает. Многократно ловил источники слива почты через этот трюк с плюсом. Никто даже не парится нрмализацию делать т.к. источники почты по-умолчанию считаются уже нормализованными.
Плюсы - это ещё мелочи. Гораздо хуже то, что многие сайты вообще разрешают регистрировать почту только на доменах крупных провайдеров вроде gmail/yandex. Объясняют они это тем, что мол этот крупняк уже верифицировал юзера, собрал телефоны/капчи, а, значит, можно быть уверенным в том, что это не бот а реальный живой человек (да, author.today, я смотрю в т.ч. на тебя!). Очевидно, что они этим по сути убивают федеративность почты. А вы тут про плюсы плачете…
Согласен, это вообще другая лига идиотизма.
Их борьба с ботами - это фейс-контроль, который разворачивает тебя в пиджаке, потому что «слишком уникальный», но пропускает толпу в одинаковых масках.
Если, баг с плюсом - это досадная мелочь, то - уже осознанный выстрел себе в ногу. Из базуки.
А ещё есть блокировка всех иностранных IP-адресов ))
В случае, если у бизнеса целевая аудитория ограничена своим районом или регионом (!= Москва, СпБ и т.д.), то почему бы и нет? Возможно, на входящем потоке сэкономят. :-).
Потому что человек может быть в этот момент в отпуске, за границей.
Когда это делает бизнес - проблемы бизнеса, а когда таким балуются государственные службы - это трындец.
Плюс, в последнее время они начали блочить и адреса впн. И получается, ты из за границы не можешь ничего сделать.
И это я не о России, а об Израиле...
Им нужен "качественный" трафик, а не "боты-однодневки". И в принципе это соотносится с основными принципами маркетинга. Ибо продукт должен быть направлен на конкретную аудиторию, а не на всех подряд. Да, возможно порежут пару процентов тех кто сидит на нишевых доменах, зато те кто пришёл почти наверняка живые клиенты и с ними можно делать... что-то непотребное по выкачиванию бабла.
Так что с точки зрения бизнеса всё более чем логично.
Внедрите нормализацию. Перед проверкой уникальности и сохранением в БД приводите email к каноническому виду. Это решит проблему с дублированием аккаунтов.
Так вы определитесь, как пользователь: вы хотите, чтобы у вас аккаунт был привязан к основному email или к алиасу? Если к алиасу, то система должна оригинальный email хранить, чтобы на него письма слать, как минимум, так что о нормализации речи быть не может. Если в канонической форме, то и плюсы всякие можно блокировать спокойно — в канонической форме из быть не может.
Представим, что ваш сервис разрешил регистрацию на user+test1@gmail.com. Что произойдет, если тот же пользователь попытается зарегистрироваться на user+test2@gmail.com
Ну, то есть, мы сначала разрешили регистрацию с email в неканонический форме, придумав себе проблему на ровном месте, а потом героически её решаем?
это ваша упущенная прибыль или потерянный лид
Сколько реальных пользователей пользуются этим функционалом и уйдут без него? Сколько денег приносят эти пользователи?
Про калечный регекс можно вообще много рассуждать. Как-то читал статью по валидацию почт от Райана Кастелуччи, у которого есть доступный(я написал ему туда письмо и получил ответ) email
`wget${ifs}r.vc/ghe`@ryanc.org
Он соответствует RFC, но пропускать такие адреса — это хитрый способ выстрелить себе в ногу в моменте, когда адрес покинет ваше RFC-compliant приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
Привет! Спасибо за наброс, тут есть что обсудить. Давай по порядку.
Про нормализацию. Тут всё просто, никакого противоречия. В базе заводят два поля: одно для логина и проверки на дубликаты (
normalized_email), другое - для отправки писем (original_email, как ввел юзер). Проблема решена.Про "упущенную прибыль". Дело не в паре гиков с плюсами. Дело в том, что для шарящих ребят кривая валидация - это как красная тряпка. Сразу видно, что к качеству тут относятся наплевательски. Так что проблема на ровном месте - это как раз запрещать рабочую фичу, а не поддерживать ее.
Про безопасность и
wget. Пример крутой, но он вообще о другом. Путать валидацию (проверку формата) и санитайзинг (обеззараживание данных) - это классическая ошибка.Винить RFC в том, что твой древний баш-скрипт можно взломать, - это как винить ГОСТ на колбасу в том, что ты этой колбасой порезался. Любые данные от юзера надо экранировать перед использованием. Всегда.
одно для логина
другое - для отправки писем
Проблема решена.
Рано. У вас теперь два поля для PII masking в логах, анонимизации для стейджа, интеграций с партнёрами. Это набор источников для интереснейших багов.
Больше того, у вас часто в системе много мест, куда можно засунуть почту — вам придётся поддерживать это везде, чтобы избежать конфузов вида: "у организации не была привязана почта, так что произошёл фоллбек на отправку письма пользователю-руководителю, но он отвалился, потому его личный адрес не прошел валидацию".
шарящих ребят кривая валидация - это как красная тряпка
Опять же, какое пресечение этих ребят с красными тряпками и decision makers?
Винить RFC в том, что твой древний баш-скрипт можно взломать
Проблема в том, что он как раз не мой — это обычно какая-то вендорская система, к которой есть доступ по API. В глубинах систем может быть IBM'овский мейнфрейм с семибитной кодировкой, который подавится юникодным имейлом, если его не канонизировать; На другом интеграции конце может быть asp.net framework приложение, которое режет запросы, когда видит в нем что-то похожее на csrf. Я пишу код для большого американского банка и там такие приколы на каждом шагу.
Вокруг множество хрупких систем, и пускать к себе на вход только чистые данные — валидная стратегия, если вы не хотите потом ругаться с полусотней вендоров, которые не принимают ваши запросы, потому что их реализация кривая. Lowest common denominator никогда не подводит.
Любые данные от юзера надо экранировать перед использованием. Всегда.
Давайте учиться читать:
когда адрес покинет ваше RFC-compliant приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
С вашей стороны всё может быть прекрасно, но ломается оно в чужом коде. Удачи править приложение, написанное на смеси C, древнего диалекта лиспа и, почему-то, D(у нас такое реально есть. Вендор-аутсорсер просто конченный), которое дергает другие команды, но не справляется с экранированием.
Рано. У вас теперь два поля для PII masking в логах, анонимизации для стейджа, интеграций с партнёрами. Это набор источников для интереснейших багов.
Нормализуйте email, добавьте соль и возьмите от этого хэш - тот же sha256 - получите заодно уникальный ключ для юзера. Можете передавать его партнёрам или писать на стене. Однако, возможна ситуация когда вы немного исправили процедуру нормализации и хэширование для уже существующих email в базе будет выдавать другой ключ. Впрочем, и без хэширования нормализованный email в базе может измениться.
По теме проверки email - как обычно, на древнем StackOverflow сохранились сокровища с примерами вроде этого. Все понимают, что надо где-то знать меру, но не все знают про эти дополнительные фичи вроде той же субадресации (RFC5233).
Однако, это уже дополнительная фича, которая может не поддерживаться почтовым сервером. Даже автор статьи в примере приводит только gmail. Однако, плюс (и минус, а также может быть и решетка #) для этого используют почти все крупные почтовые сервисы. Фича с точками - только у gmail AFAIK, но ещё могут быть корпоративные домены, которые хостятся на gmail, а так же более мелкие сервисы. Просто так нормализация - довольно непростой процесс.
Можете передавать его партнёрам
Партнеры хотят сырой имейл, а не ID / хэш.
Я расскажу страшную историю: у нас недавно отвалилась интеграция с одним из партнеров. Они интегрируются по стандартизированному SOAP, принимая не менее стандартизированный MISMO-документ, для которого есть DTD, по которому можно собрать десериализацию с нулём ручного кода. Казалось бы, что может пойти не так?
Выяснилось, что у партнёра не реализован SOAP на самом деле — они принимают сырое тело SOAP-запроса и парсят через поиск подстрок, не используя даже стандартный XML-парсер. Предсказуемо, оно развалилось, когда мы им новое поле, включённое в стандарт, стали отправлять.
Именно из-за таких историй надо бить линейкой по пальцам за попытки разрешить пользователям использовать полный стадарт RFC на почты, телефоны по E.164 с поддержкой допномеров, юникод в полях, которые для него не предусмотрены и подобного — даже самая современная система опирается на огромный карточный домик существующего легаси из говна и палок, который разваливается, если попытаться затолкать в него хоть что-то нестандартное.
Ну так-то отвалиться может что угодно. Они могут вообще распечатывать ваш xml и прогонять через OCR, а потом диктовать слепому наборщику текстов по телефону со стадиона - и вы ничего с этим не сделаете.
А про SOAP - ну так-то там много стандартов наверчено вокруг. Я года 4 назад честно пытался начать работать с сервисом, который в SOAP использует ws-addressing и кучу подписей в документе и в транспорте. В итоге оказалось, что ни в одной Python библиотеке просто не поддерживается одна из особенностей - что-то там не подписывалось правильно и все мои попытки самому починить ни к чему не привели. В итоге, после трёх месяцев я нагуглил у собратьев по несчастью что в php это как-то работает и всё закончилось костылём где я из python вызываю php для отправки файла.
А этот SOAP-сервис, который сначала был стройно разбит на несколько wsdl и xsd файликов уже через пару лет превратился в сборище разных версий этих xsd, которые ссылаются друг на друга в хаотичном порядке.
Простите, наболело.
Они могут вообще распечатывать ваш xml и прогонять через OCR
Вы не поверите, но такое тоже есть. У нас один из партнёров не всегда консистентные данные между XML и PDF-кой договора присылает, так что мы парсим PDF для валидации, и ничего, не жужжим. Причём эта контора активами на триллионы долларов управляет и не работать с ними нереально — когда ОП пишет про прошаренных чуваков, отказывающихся от услуг, когда видят валидацию не по RFC, сразу ясно, что в серьёзном бизнесе не работал.
Ну так-то отвалиться может что угодно.
Может, так что не надо обострять ситуацию, собирая эджкейсы.
Дело в том, что для шарящих ребят кривая валидация - это как красная тряпка
А нужны ли такие шарящие ребята? Они умные, скорее всего. На дарк паттерны не ведутся, на спам не отвечают, адблоком пользуются, ещё и ПД свои стараются не светить.
Для современных корпораций это они красная тряпка. Пусть лучше идут шарить в другое место, главное чтоб Мариша с ноготочков смогла зарегаться и её можно было бы окучить.
У бизнеса два выбора: делать сервис для «Мариши» или для «гиков».
Но фишка в том, что «гик» - это как ресторанный критик. Да, он привередливый и на скидки не ведется. Но если уж ты смог накормить его так, что он остался доволен, то «Маришка» точно не отравится и будет в восторге.
А вот сервис, сделанный только для «Мариши», рано или поздно сломается, и пострадает именно она.
Так что «шарящие ребята» - это не проблема. Это бесплатный отдел качества, который работает на всех.
Если хранить две формы адреса, то утекут обе, и вы не решите главную задачу - идентификацию утечки.
Значит вместо канонизированного адреса надо брать от него хэш.
Особо упоротые ещё могут и длину e-mail ограничить.
удивительно что ты поднял эту проблему только сейчас, повальное тупение разработчиков началась лет 15..20 назад, и по бессилию перестал пользовать тегирование и забыл уже и думать об этом. но тему нужно поднять выше
Не удивлюсь, если скоро появятся плагины для браузера, каким-либо образом заставляющие кривой валидатор на фронтэнде вернуть true. Ведь ребятки, не умеющие валидировать емейлы, не считают проблемой делать валидацию во фронтэнде.
У браузеров уже есть механизм для проверки e-mail так-то:
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/email
Потенциально валидацию можно сделать через сертификаты и взаимные печеньки (чтобы исключить ддос-ы) условных доверенных центров (юзер всё равно где-то проходит двойную аутентификацию в крупных структурах а-ля гуглы и прочие Госуслуги), когда фронтенд или бэкенд может выполнить нечто вроде "whois email" на сервер а тот ответит валиден этот юзер или нет как настоящее физлицо. Тогда проблема парсинга отпадает сама собой.
На всякий случай: '_' (состоящий из трех символов) валидный username для почты.
А кто-нибудь в курсе, почему стандартный input type = email никто не использует?
Ребята, вы теряете пользователей, которые хотят запретить вам спамить! Не делайте так!
Ещё из недавнего: совсем недавно на линкаче ржали с валидации ящика:
def is_valid(input):
if "@" not in input:
return False
if "." not in input:
return False
return Trueimgonna.spam@you тут же передал привет.
Gmail игнорирует точки в адресах.
my.user@gmail.com,myuser@gmail.comиm.y.u.s.e.r@gmail.com— это один и тот же ящик. Блокировать точки вы будете?
Что-то сколько раз ни пытался этим трюком воспользоваться, всё время письмо «в молоко» уходило, это точно работает?
Gmail игнорирует точки в адресах
Подождите, подождите. Это как? Мой гуглоаккаунт содержит точки. Когда я его делал, то нужное мне имя было занято. Я добавил точки, как разделители, и все получилось. То есть вы хотите сказать, что имя1.имя2@gmail.com и имя1имя2@gmail.com - одно и то же? Нет, не могет такого быть. Это же означает, что я делю свою почту с каким-то неведомым чуваком. Стоп, речь идет не просто про почту. Это совместный гуглоаккаунт! "Да нет, бред какой-то..."©
Интересная теория. Может, тот чувак удивляется, куда девается часть его почты, а он у вас в спаме.
Конечно, давно интернет полон жалоб https://www.reddit.com/r/GMail/comments/jsmcmo/gmail_dots_apparently_do_matter_i_keep_getting/
Но гуглу пофиг. Там какого спамера наняли, который во все жалобы копипастит одно и то же.
читаем мануалы: https://support.google.com/mail/answer/7436150?hl=en
Да, это так. Я получаю письма для двух человек которые поставили точку в адресе ящика.
я 20 лет пльзуюсь почтой и никогда не использовал +. Порядок во входящих прекрасно можно организовать и в UI.
Притом скорее 99% моих знакомых про плюс и н езнает.
Не говоря о том, что почта это атавизм и хорошо бы от неё отказываться.
ТАк что думаю coolservice переживёт без пары пользователей, которые очень захотели поюзать стандарты
Не говоря о том, что почта это атавизм и хорошо бы от неё отказываться.
Чем предлагаете заменить?
Не согласен. Ниже опишу своё мнение, которое я никому не навязываю.
"+" я пользуюсь давно и это удобно при сортировке почты. про "." не знал, но теперь знаю. про "___" - это занимательно.
почта удобна, особенно, когда нужно найти важную переписку. мессенджеры тут и рядом не стояли.
предпочитаю почтовые клиенты, а не online, т.к. доступ к online могу закрыть в любой момент (ну, или сама почтовая система перестанет существовать), а письма на диске останутся.
если что, с "никогда такого не произойдёт" я уже несколько раз сталкивался.не могу не вспомнить про RSS. я его до сих пор использую, если сайты поддерживают этот вариант (и, кстати, опять же, через почтовый клиент).
к сожалению их становится меньше - его тоже считают атавизмом.
проще пролистать сообщения из RSS, чем на сайте листать ленту. так я с большей вероятностью найду понравившийся мне материал.
к счастью, habr пока поддерживает его и буду надеяться, что поддержка не прекратится.
Замечательная функция, о которой я не знал.
Попробовал отправить себе на gmail пару писем с этими плюсами.
ожидание: письмо с "плюсовым тегом", автоиатически, падает в соответствующую папку.
реальность: все эти плюсы лежат во входящих и нужно настраивать дополнительные правила сортировки или применять "поиск в почте".
Думал, сначала, что так себя ведёт почтовый клиент на телефоне, но и в компьютерном браузере вижу такое же поведение.
Правильное решение: перед сохранением в базу данных email нужно нормализовать — привести к каноническому виду.
"Проблема" создана на стороне пользователя. Он же и знает как её решать.
Когда у тебя свой домен, можно поднять на нём почту, и разделять сервисы по локальной части email'а. Но даже так довольно часто сталкиваешься с проблемами:
Список разрешённых доменов первого уровня, в котором например нет .pro
Жесткая привязка в gmail.com
Приложение, которое создано для использования в корпоративной среде, имеет ограничение на длинну домена и/или список разрешённых доменов первого уровня.
И вот на фоне таких проблем, неподдержка плюса уже не кажется проблемой.
Пользуюсь почтой на своих доменах (но из старого набора) уже лет 15.
Но при регистрациях использую только то, что автор поста использовал бы после плюса.
То есть, при регистрации, например, на нетфликсе - netflix@mydomain.tld
Такой подход идеален.
чтобы сайт не терял пользователей из-за тега после плюса, его, этот +тег сервису надо опускать для любых важных целей, типа авторизации в сервисе идентификации пользователя, отправки платёжных документов, а вот для отсылки рекламы самое то и пользователь рад, что тегирование работает. То есть сервис должен понимать, что после плюса это не часть адреса, а просто декоративный тег для удобства пользователя.
UPD. Получается, если сервисы начнут правильно разбирать мыло и узнавать +тег, то идея использовать +тег для защиты от спама и поиска того кто слил мыло снова накроется.
Как то я при регистрации на сайте к email добавил +SiteName и все было успешно пока я не решил авторизоваться, оказалось окно email имеет длину ввода символов больше при регистрации чем при авторизации, и я бл... попал в этот промежуток, мне писали что email слишком большой, ПРИ АВТОРИЗАЦИИ!!!. Я уже точно не помню, но больше я не мог использовать эту почту на том сайте.
if '@gmail.com' not in email and '@googlemail.com' not in email:
А если кто-то сделает адрес в домене вроде gmail.com.example.ru?
Вообще говоря подобного рода стандарты появились, когда что-то из курилок Bell Labs в 70-е было уже де-факто, а потом оформилось де-юре, это же касается и тех самых языков программирования. Поэтому простое следование означает, что потенциально останется аудитория, которая знает как сделать тонкий клиент Радио-86РК программатором ЭПСН-25.
Не сегодня так завтра появится Undecillion co. которая скажет что в духе нашей команды теперь в почте и домене могут быть пробелы-смайлики и полный набор Unicode. А наше дополнение позволяет резольвить любое поле аутентификации в наш SunnyFlare с бонусной годовой подпиской как API с функционалом почты, поэтому обходитесь без назойливой @. Браузер WaterDog наконец-то поддерживает сплит-поля в одном теге где отдельно вводится идентификатор, субидентификатор и домен, равно как нормально парсятся даты, время и часовые пояса. Поэтому, лучше следовать самым современным и актуальным нововведениям и сосредоточиться на разделении потоков потенциальных ошибок и ущерба от них на классы по времени восстановления с точки зрения безопасности.
Есть ещё отдельное направление List-Request со знаком минус и прочая автоматизация по образу Git
Так пробелы и смайлики могут быть. Стандарт почты поддерживает любую строку, если её экранировать кавычками в начале и конце. Просто такую дичь вообще почти никто не использует, но она возможна.
А ещё у меня когда-то была почта на домене @фирмы.онлайн , прям по-русски, да. И письма ходили… но не везде.
Правильное решение: перед сохранением в базу данных email нужно нормализовать — привести к каноническому виду.
Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
Исправьте свой RegEx!
Проблема возникла ввиду того, что адрес почты это объект и практически имеет поведение, то есть имя содержит дополнительные элементы-теги, влияющие на поведение сервера. Исторически получилось так что Username == Email, поэтому конечный пользователь а-ля тётя Юля (для многотысячной посещаемости там 99 таких, включая ботов) не будет утруждать себя чтением RFC. Это скорее нужно администраторам и разработчикам. Особенно там где сложилось так что почта используется в режиме мессенджера и автоматизации рассылки как mailing lists, снабжая адресата суффиксами +- итд. По сути сейчас идёт трансформация почты в чат, поэтому, скорее всего, автоматизацию из имён скорее всего уберут или оставят как unsupported.
Мой коммент скорее про то, что у email нет канонического вида. У каждого сервера свои правила - тот же гугл - наверное единственный, кто точку в адресе игнорирует.
А по поводу нормализации для ДБ - я, как пользаватель, ожидаю что user+test1@gmail.com и user+test2@gmail.comкак раз два разных адреса с точки зрения сервиса. Ну и как бы email-адреса авторизации скрывать принято.
А если сервис боится, что пользователь зарегистрирует два аккаунта, то ему придётся с этим смериться. Пользователь может создать второй ящик.
Всё верно, просто с точки зрения пользователя, у которого есть суффиксы, может возникнуть неопределённое поведение, он ждёт от сервера обработку запроса на основании имени. Другой вопрос зачем он этот суффикс использует для юзернейма, регистрации итд вне почтового клиента. То есть вне рамок SMTP канонического вида нет и все адреса хоть с + хоть с - являются уникальными и независимыми. Но если сайт предполагает взаимодействие с именем почты как с объектом и обработкой тегов то он уже должен хранить его в приведённом виде. Это скорее вопрос соглашений и на него однозначного ответа нет.
Мой коммент скорее про то, что у email нет канонического вида.
Ваистену так
...благодаря длинной череде проблем, вызванных промежуточными хостами, пытавшимися оптимизировать передачу путём изменения их [адресов], локальная часть ДОЛЖНА быть интерпретирована (и ей должен быть назначен семантический смысл) исключительно сервером, указанным в доменной части адреса.
Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
Тут имеется в виду сохранять нормализованный вариант во вспомогательном поле. Основное поле, используемое для авторизации, отправки сообщений, будет содержать неизменённый email. И использовать его только для проверки дубликатов.
А зачем их вообще проверять? Я, как пользователь, ожидаю, что сервис их будет обрабатывать именно как два разных ящика.
Вы знаете, этот подход тоже имеет место быть. Тут всё зависит от логики системы. Если системе нужны "уникальный адреса", то они будут фильтровать. Если системе это не важно (и пользователи не злоупотребляют этим - а, злоупотребление и есть основная причина добавления проверки), то она будет работать со всеми адресами.
Кстати, в одной системе я, как раз, тоже использую "+" для поддержки двух аккаунтов - не хотел заводить новую почту. Да, и для новой почты становится обязательным новый номер телефона.
Вообще говоря, это уже задача фронтенда и, по-хорошему, должно появляться всплывающее второе поле при наличии любых суффиксов и галочка для пользователя "считать имя составным" если это критически важно для механизма взаимодействия сайта на основе почты (рассылка, уведомления итд). То есть поддержка стандарта уже реализуется на уровне интерфейса, так как иными методами указать явно это не получится. В этом случае сайт для аутентификации использует каноническое представление.
Эта боль - неотъемлемый атрибут всех спецификаций с поведением. Даже ASCII с его перевод строки и возврат каретки, звонок Bell или управляющие последовательности для телетайпа-принтера. По аналогии можно заставить обычным текстом условного имени пользователя пропищать динамик или выплюнуть бумагу при печати заголовка.
Я не говорю что такого не существует или не должно существовать, но я ни разу не видел сервиса который мы давал имя пользователя на основе email. Это всегда заполняемое вручную поле. И если я ввёл адрес с суффиксом - это значит я хочу получать корреспонденцию от сервиса именно на имя с суффиксом.
Эта боль - неотъемлемый атрибут всех спецификаций с поведением.
Сохраните email как его ввёл пользователь и не пытайтесь его обработать:
https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.11
Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
Вы абсолютно правы с точки зрения формального подхода 1 поле = 1 данное без разночтения. С другой стороны есть приверженцы обрядов. Вообщем вывод напрашивается сам собой и носит по всей видимости чисто административный характер - писать свои предложения в Спортлото RFC. "Подать жалобу. Коллективную (С)" Чтобы уже привели всё в нормативы 21 века.
В принципе так и делается если существует некая точка которая мешает ввиду того что когда-то она была принята с аргументом нам жалко 2 байта на дату, а потом все бегают с проблемой 2000-го года. Хотя грядёт ещё 2^32 в 2038 году.
Это должна быть совместная работа W3C, IEEE, RFC итд итп, но там по всей видимости... Линус прав. Основным мейнтейнерам этого дела уже почти за 70. Поэтому новые разработчики вынуждены будут учиться по тем шаблонам которые закреплены и забетонированы как стандарт пока сами не предложат новое.
PS Если кому-нибудь, вытащенному из модемных 90-х сказать что в браузере в строку адреса можно будет сразу писать поисковый запрос вместо URL вида http://www.... то 8-[
Если кому-нибудь, вытащенному из модемных 90-х сказать что в браузере в строку адреса можно будет сразу писать поисковый запрос вместо URL вида http://www.... то 8-[
Если кому‑то, вытащенному из 2010-х, сказать что в браузере в строку адреса можно сразу написать URL вида http://mail.ru вместо того, чтобы печатать «mail.ru» в поиске тындекса...
Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
А как же регистр? Юзер зарегистрировался как "vasya@gmail.com" и пытается зайти с "Vasya@gmail.com" - тоже не надо преобразовывать?
Вроде сейчас обычная практика при логине по email локальный пароль не заводить, для авторизации присылать одноразовый пин на почту - так что ничего преобразовывать не надо.
Так а пользователя-то как находить в базе при логине? Это же один аккаунт. Пароль тут совсем не при чём. Вопрос в том - как хранить email в базе.
Хранить в базе - точно без преобразований, но сравнение на равенство с учётом эквивалентности по RFC.
И в теории локальная часть адреса case sensitive, просто некоторые (сейчас, видимо, подавляющее большинство) почтовые сервера раскидывают письма по пользователям без учёта регистра.
Ну тогда мы снова вступаем на скользкую дорожку - разные ли пользователи "Vasya" и "vasya"? Тут проблема с плюсом уже - частный случай.
Но я ни разу не встречал сервиса где такое разрешалось. Наверное и правильно.
Правильнее всё таки следовать RFC.
Всё верно, просто если стандарт имеет, как было любезно указано выше участником Krypt, строки "due to a long history of problems", это означает что он частично является костылём к го́ре или горе́ легаси. Поэтому, будет соблазн однозначно идентифицировать пользователя, инкапсулировав адрес в промежуточное представление, например UUID_имя@домен или даже Base64_имя@домен. А имя может содержать хоть байткод/анекдот. То есть появятся некие сервисы которые завернут SMTP в более высокоуровневые конструкции актуальные в настоящее время. В эту же копилку номер телефона == мейл.
То есть в случае для входа используется именно пара email/пароль?
Логика говорит, что наверное стоит спрашивать email как он был введён пользователем изначально. Пользователь знал, что он делал. Наверное.
Кроме, может быть, таки регистра, потому что многие считают и ожидают что email регистронезависим. А если нужно отправить email - использовать адрес в точности как его ввёл пользователь. Если вы при регистрации отправляли письмо и пользователь подтвердил получение - то вы уже знаете, что письмо дойдёт.
Не надо. И таки да, по RFC это два разных email:
https://datatracker.ietf.org/doc/html/rfc5321#section-2.4
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".
С практической точки зрения, если адрес электронной почты сильно отличается от обычных адресов, то это скорее попытка взлома, а не реальная необходимость использования email нетипичного вида, хотя и формально корректного.
ты должен был бороться со злом, а не примкнуть к нему!
ТС озвучил очень неприятный для гиков баг - за это конечно же +. Но предложил решить его ужаснейшим образом через нормализацию - за это точно -.
Что те кто не поддерживают регистрацию с плюсами, что те кто не поддерживают регистрацию разных аккаунтов на алиасы - ограничивают меня как пользователя в правах. Предпочитаю обходить такие сайты стороной
Идея гениальна в своей простоте: почтовый сервер, получая письмо на адрес
localpart+tag@domain.com, должен доставить его в ящикlocalpart@domain.com, проигнорировав+tag.
А чем это принципиально отличается от обычных комментариев в email адресе?
Тут разработчик может просто сделать два поля. Одно логин с плюсом, второе без него. При регистрации отбрасывать все то, что за плюсом и сравнивать по второму полю. Если уже запись есть отправлять соответствующие предупреждение любителям мультиакков.
Но это всю систему ломать нужно. Про этот плюс может только один продвинутый из 10 000 знает. Лично я, вечером добавлю такой момент в свои скрипты регистрации.
Вы забыли добавить весь алфавит UNICODE в регулярное выражение. Иероглифы там же.
Универсальное принятие, которое играет из колонок уже несколько лет, планомерно просит все сервисы и приложения принимать введенную почту как есть. Вы можете попытаться провести её проверку многоуровневыми проверками вплоть до обращения к DNS для проверки валидности указанного домена (проверка@пример.испытание был валидным адресом и домен резолвился), но никогда не сможете поддерживать в актуальности эту проверку. Одна из рекомендаций - использовать публичные библиотеки по валидации. Но учитывая нашу лень и прибивание гвоздями версии библиотек, тоже будут ошибки.
В дискуссии с авторами этого всего было выдвинуто предложение - просто попробуйте доставить туда письмо. Если дошло (не вернулось или кликнули по ссылке и подтвердили адрес) - адрес валидный.
メール@例.テスト
У меня был свой почтовый сервер и алиас я настроил через точку, так раз чтоб такого избежать, но вылезла другая проблема на некоторых сервисах, домен верхнего уровня .email считают невалидным, мол больше 3 символов ))
Gmail игнорирует точки в адресах
У меня всю жизнь gmail аккаунт содержал точку (типо ник1.ник2@gmail.com) сейчас попробовал зарегать акк без точки и всë получилось (по типу ник1ник2@gmail.com)
А за плюсы спасибо буду пользоваться (правдо на сайтах с нормализацией в теории работать не должно)
Кмк самая правильная валидация - это пускать все типа <что-то>@<что-то> и пытаться либо начать SMTP хендшейк, либо реально отправить письмо со ссылкой для активации.
А по поводу нормализации - что ввели то и храним (после strip && lowercase).
Нельзя lowercase. email case sensitive в общем случае.
"Не приветствуется" и "никогда не случится" - это разные вещи.
Лично я исхожу из принципа, что нужно следовать пессимистичному сценарию:
- С точки зрения сервиса отправляющего почту - что адреса должны быть именно в той форме, в которой адрес дал ему пользователь, иначе почтовый сервис не доставит письмо.
- С точки зрения почтового сервера - что сервис отправляющий почту будет творить всякую ересь вроде попытки "канонизировать" адрес только по одному сервису известному принципу.
А я лично исхожу из соображений совместимости. Большинство крупных сервисов case-insensitive. У себя я тоже так сделал.
Я вот даже не вспомню сходу у кого case-sensitive.
Аналогично. Я не говорю что вы должны делать case sensitive на почтовом сервере. В rfc написано сервер может делать с ними что ему вздумается, пока он следует корректному синтаксису адресов. Хоть всю почту в один ящик скинуть.
Вопрос именно в том, как сторонние сервисы воспринимают адрес получателя. Для максимальной совместимости "нормализовать" (к чему?) и менять регистр нельзя.
Я немного потестил ms/gmail - в целом им пофиг на регистр. При отправке, например to: John@doe.com, cc: jOhn@doe.com уходит реально только первое, cc и все остальные одинаковые отбрасываются.
По опыту общения с разными пользователями крупных сервисов они тоже не различают кейс, вполне могут написать свой адрес как JohnDoe@gmail.com, AnotherJohn@gmail.com, ANOTHERJOHN@GMAIL.COM, и т.п.
Так что логично для большей совместимости со всеми у себя исключить возможность заведения одинаковых адресов, отличающихся только регистром, и обрабатывать без его учета.
Дико плюсую. Постоянно использую плюсик при регистрации, именно как метку для контроля утечки спама, и бесит что многие современные сайты (включая солидные конторы) отказываются его принимать.
О! Как раз на днях пытался зарегаться на какой-то ивент крутейшей (по их словам) сетевой компании selectel мылом с плюсиком. Не пущщает. Из вредности написал в поддержку. Поддержка здорового человека сказала бы, - погоди, ща починим. - Но поддержка курящего селектела с гордостью ответила, - да, мы таких уродов не регаем и регать не будем!
Причём на каком-то другом соседнем их же сервисе мыло с плючиком без проблем пролезло.
я искренне не понимаю на кой проверять почту регулярками, чем не устраивает проверка наличия просто @ и даже в ней то смысла не то чтоб много
Ваш сайт теряет пользователей прямо сейчас. Виноват один символ: '+' в email