Привет, Хабр! Представьте ситуацию: вы нашли крутой сервис, регистрируетесь, вводите свой email my.name+coolservice@gmail.com (ведь вы, как и я, любите порядок во входящих) и… получаете ошибку «Некорректный email». Знакомо? Уверен, что да.
Каждый раз, когда я сталкиваюсь с таким, у меня дергается глаз. Это не просто мелкий баг. Это симптом глубокой проблемы в подходе к разработке и непонимания базовых стандартов. Давайте раз и навсегда разберемся, почему сервисы не принимают почту с «плюсом», почему это плохо для бизнеса и, главное, как это исправить.
Как должно работать: магия субадресации по RFC 5322
Для начала — немного теории. Существует стандарт RFC 5322, который описывает формат электронных почтовых адресов. И этот стандарт черным по белому разрешает использование символа + в локальной части адреса (до символа @).
Эта фича называется субадресация (sub-addressing), или "plus addressing".
Идея гениальна в своей простоте: почтовый сервер, получая письмо на адрес localpart+tag@domain.com, должен доставить его в ящик localpart@domain.com, проигнорировав +tag.
Пример:
Все письма, отправленные на адреса:
...придут в один ящик: user@gmail.com.
Это невероятно удобно. Пользователи могут:
Автоматически фильтровать входящие. Настроил правило в почтовом клиенте — и все письма с тегом
+workпадают в папку «Работа».Отслеживать спам и утечки. Зарегистрировался на сайте
super-shop.comс почтойuser+super-shop@gmail.com. Если на этот адрес вдруг повалится спам от «Рога и копыта», вы точно знаете, кто слил вашу базу.
Эту фичу поддерживают все гиганты: Gmail, Outlook, iCloud, ProtonMail. Миллионы, если не сотни миллионов, технически грамотных пользователей по всему миру активно ею пользуются. И когда ваш сервис говорит им, что их email «неправильный», он, по сути, хлопает дверью у них перед носом.
Почему всё ломается? Пять причин нелюбви к «плюсам»
Проблема почти никогда не бывает на стороне почтового провайдера. Она сидит глубоко в коде вашего приложения.
Причина 1: Фронтенд-валидация и ленивый RegEx (самая частая)
9 из 10 случаев — это кривая валидация на фронтенде. Разработчик, получив задачу «проверить email», идет в Google, копирует первый попавшийся паттерн для регулярного выражения (RegEx) и вставляет его в код.
Типичный «плохой» RegEx выглядит так:
// Где-то в коде формы регистрации
const emailRegex = /^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,6}$/;
if (!emailRegex.test(emailInput.value)) {
showError("Введите корректный email!");
}
Видите здесь +? Я тоже нет. Результат — мгновенная ошибка в интерфейсе и разочарованный пользователь.
Причина 2: Бэкенд-дублирование
Если фронтенд-проверку можно обойти через DevTools, то бэкенд — это вторая линия обороны. И часто там стоит тот же самый «увечный» RegEx. Это делается для безопасности, чтобы злоумышленник не отправил на сервер некорректные данные в обход интерфейса. Но если валидация некорректна, она просто блокирует легитимных пользователей.
Причина 3: Иллюзия борьбы с абузом
Некоторые менеджеры и разработчики осознанно блокируют +, считая это мерой безопасности.
Их логика: «Если мы разрешим плюсы, один человек сможет создать 100 аккаунтов на одну почту и абузить наши промокоды для новых пользователей!»
-
Почему эта логика порочна:
Gmail-хак с точками: Gmail игнорирует точки в адресах.
my.user@gmail.com,myuser@gmail.comиm.y.u.s.e.r@gmail.com— это один и тот же ящик. Блокировать точки вы будете?Временные почты: Существуют десятки сервисов временных email, которые решают задачу абуза гораздо эффективнее.
Вы наказываете всех: Пытаясь остановить горстку мошенников, вы создаете проблемы для тысяч добросовестных клиентов. Это все равно что заварить все двери в здании, потому что кто-то может войти без спроса.
Причина 4: Проблемы с уникальностью в БД
Это более тонкий момент. Представим, что ваш сервис разрешил регистрацию на user+test1@gmail.com. Что произойдет, если тот же пользователь попытается зарегистрироваться на user+test2@gmail.com?
С точки зрения системы, это два разных email. А с точки зрения пользователя — один. Если у вас в базе email является уникальным ключом, вы позволите создать два аккаунта, привязанных к одному реальному ящику. Это может привести к путанице с восстановлением пароля, подписками и т.д.
Правильное решение: перед сохранением в базу данных email нужно нормализовать — привести к каноническому виду.
# Пример нормализации на Python
def normalize_email(email):
"""
Приводит email к каноническому виду для хранения в БД.
normalize_email('My.User+test@gmail.com') -> 'myuser@gmail.com'
"""
if '@gmail.com' not in email and '@googlemail.com' not in email:
return email.lower()
local_part, domain = email.split('@')
# Убираем все после '+'
local_part = local_part.split('+', 1)[0]
# Убираем все точки
local_part = local_part.replace('.', '')
return f"{local_part}@{domain}".lower()
Нормализованный email уже можно использовать для проверки на уникальность.
Причина 5: «Я не знал»
Банально, но факт. Многие разработчики просто не знают о существовании субадресации. Они пишут код, исходя из своего опыта, а в их мире email — это просто буквы@буквы.домен.
Что делать? Чек-лист для команд
Это не просто баг, это — лакмусовая бумажка зрелости вашего продукта.
Для QA-инженеров:
Проверяйте это всегда. Добавьте в свой чек-лист регистрации/авторизации кейс с email, содержащим
+.-
Заводите баг-репорт правильно. Не пишите просто «не работает почта с плюсом».
Тема: «Форма регистрации не принимает валидные email-адреса с субадресацией (содержащие '+'), нарушая стандарт RFC 5322».
Обоснование: Укажите, что это блокирует регистрацию для большой группы пользователей Gmail/Outlook и вредит репутации продукта. Приложите ссылку на RFC.
Ожидаемый результат: Система должна успешно принимать и обрабатывать такие адреса.
Для разработчиков:
-
Исправьте свой RegEx! Вот более адекватный вариант, который пропускает
+(но он не идеален, идеальный RegEx для email занимает страницы):// Простой, но уже лучше const betterEmailRegex = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/;Но лучше всего использовать проверенные библиотеки для валидации, а не писать свои велосипеды.
Внедрите нормализацию. Перед проверкой уникальности и сохранением в БД приводите email к каноническому виду. Это решит проблему с дублированием аккаунтов.
Для менеджеров продуктов:
Не отмахивайтесь от этого бага как от мелочи. Каждый пользователь, который не смог зарегистрироваться, — это ваша упущенная прибыль или потерянный лид. Инвестиции в исправление этой проблемы — это инвестиции в пользовательский опыт и рост вашей аудитории.
Заключение
Проблема с + в email — это классический пример того, как пренебрежение стандартами и фокус на сиюминутных задачах приводят к системным ошибкам, бьющим по бизнесу.
Давайте уважать наших пользователей и стандарты, на которых держится интернет. Откройте свой проект прямо сейчас и проверьте: а вы дружите с плюсами?
Спасибо за внимание! Делитесь в комментариях своим мнением :)
Комментарии (116)
powerman
22.07.2025 21:42Плюсы - это ещё мелочи. Гораздо хуже то, что многие сайты вообще разрешают регистрировать почту только на доменах крупных провайдеров вроде gmail/yandex. Объясняют они это тем, что мол этот крупняк уже верифицировал юзера, собрал телефоны/капчи, а, значит, можно быть уверенным в том, что это не бот а реальный живой человек (да, author.today, я смотрю в т.ч. на тебя!). Очевидно, что они этим по сути убивают федеративность почты. А вы тут про плюсы плачете…
kbones Автор
22.07.2025 21:42Согласен, это вообще другая лига идиотизма.
Их борьба с ботами - это фейс-контроль, который разворачивает тебя в пиджаке, потому что «слишком уникальный», но пропускает толпу в одинаковых масках.
Если, баг с плюсом - это досадная мелочь, то - уже осознанный выстрел себе в ногу. Из базуки.
0xC0CAC01A
22.07.2025 21:42А ещё есть блокировка всех иностранных IP-адресов ))
georgevp
22.07.2025 21:42В случае, если у бизнеса целевая аудитория ограничена своим районом или регионом (!= Москва, СпБ и т.д.), то почему бы и нет? Возможно, на входящем потоке сэкономят. :-).
Shtoka
22.07.2025 21:42Потому что человек может быть в этот момент в отпуске, за границей.
Когда это делает бизнес - проблемы бизнеса, а когда таким балуются государственные службы - это трындец.
Плюс, в последнее время они начали блочить и адреса впн. И получается, ты из за границы не можешь ничего сделать.
И это я не о России, а об Израиле...
R3B3LL10N
22.07.2025 21:42Им нужен "качественный" трафик, а не "боты-однодневки". И в принципе это соотносится с основными принципами маркетинга. Ибо продукт должен быть направлен на конкретную аудиторию, а не на всех подряд. Да, возможно порежут пару процентов тех кто сидит на нишевых доменах, зато те кто пришёл почти наверняка живые клиенты и с ними можно делать... что-то непотребное по выкачиванию бабла.
Так что с точки зрения бизнеса всё более чем логично.
kasthack_phoenix
22.07.2025 21:42Внедрите нормализацию. Перед проверкой уникальности и сохранением в БД приводите email к каноническому виду. Это решит проблему с дублированием аккаунтов.
Так вы определитесь, как пользователь: вы хотите, чтобы у вас аккаунт был привязан к основному email или к алиасу? Если к алиасу, то система должна оригинальный email хранить, чтобы на него письма слать, как минимум, так что о нормализации речи быть не может. Если в канонической форме, то и плюсы всякие можно блокировать спокойно — в канонической форме из быть не может.
Представим, что ваш сервис разрешил регистрацию на user+test1@gmail.com. Что произойдет, если тот же пользователь попытается зарегистрироваться на user+test2@gmail.com
Ну, то есть, мы сначала разрешили регистрацию с email в неканонический форме, придумав себе проблему на ровном месте, а потом героически её решаем?
это ваша упущенная прибыль или потерянный лид
Сколько реальных пользователей пользуются этим функционалом и уйдут без него? Сколько денег приносят эти пользователи?
Про калечный регекс можно вообще много рассуждать. Как-то читал статью по валидацию почт от Райана Кастелуччи, у которого есть доступный(я написал ему туда письмо и получил ответ) email
`wget${ifs}r.vc/ghe`@ryanc.orgОн соответствует RFC, но пропускать такие адреса — это хитрый способ выстрелить себе в ногу в моменте, когда адрес покинет ваше RFC-compliant приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
kbones Автор
22.07.2025 21:42Привет! Спасибо за наброс, тут есть что обсудить. Давай по порядку.
Про нормализацию. Тут всё просто, никакого противоречия. В базе заводят два поля: одно для логина и проверки на дубликаты (
normalized_email), другое - для отправки писем (original_email, как ввел юзер). Проблема решена.Про "упущенную прибыль". Дело не в паре гиков с плюсами. Дело в том, что для шарящих ребят кривая валидация - это как красная тряпка. Сразу видно, что к качеству тут относятся наплевательски. Так что проблема на ровном месте - это как раз запрещать рабочую фичу, а не поддерживать ее.
-
Про безопасность и
wget. Пример крутой, но он вообще о другом. Путать валидацию (проверку формата) и санитайзинг (обеззараживание данных) - это классическая ошибка.Винить RFC в том, что твой древний баш-скрипт можно взломать, - это как винить ГОСТ на колбасу в том, что ты этой колбасой порезался. Любые данные от юзера надо экранировать перед использованием. Всегда.
kasthack_phoenix
22.07.2025 21:42одно для логина
другое - для отправки писем
Проблема решена.Рано. У вас теперь два поля для PII masking в логах, анонимизации для стейджа, интеграций с партнёрами. Это набор источников для интереснейших багов.
Больше того, у вас часто в системе много мест, куда можно засунуть почту — вам придётся поддерживать это везде, чтобы избежать конфузов вида: "у организации не была привязана почта, так что произошёл фоллбек на отправку письма пользователю-руководителю, но он отвалился, потому его личный адрес не прошел валидацию".
шарящих ребят кривая валидация - это как красная тряпка
Опять же, какое пресечение этих ребят с красными тряпками и decision makers?
Винить RFC в том, что твой древний баш-скрипт можно взломать
Проблема в том, что он как раз не мой — это обычно какая-то вендорская система, к которой есть доступ по API. В глубинах систем может быть IBM'овский мейнфрейм с семибитной кодировкой, который подавится юникодным имейлом, если его не канонизировать; На другом интеграции конце может быть asp.net framework приложение, которое режет запросы, когда видит в нем что-то похожее на csrf. Я пишу код для большого американского банка и там такие приколы на каждом шагу.
Вокруг множество хрупких систем, и пускать к себе на вход только чистые данные — валидная стратегия, если вы не хотите потом ругаться с полусотней вендоров, которые не принимают ваши запросы, потому что их реализация кривая. Lowest common denominator никогда не подводит.
Любые данные от юзера надо экранировать перед использованием. Всегда.
Давайте учиться читать:
когда адрес покинет ваше RFC-compliant приложение и в глубинах легаси окажется в неэкранированном виде в баш-скрипте.
С вашей стороны всё может быть прекрасно, но ломается оно в чужом коде. Удачи править приложение, написанное на смеси C, древнего диалекта лиспа и, почему-то, D(у нас такое реально есть. Вендор-аутсорсер просто конченный), которое дергает другие команды, но не справляется с экранированием.
baldr
22.07.2025 21:42Рано. У вас теперь два поля для PII masking в логах, анонимизации для стейджа, интеграций с партнёрами. Это набор источников для интереснейших багов.
Нормализуйте email, добавьте соль и возьмите от этого хэш - тот же sha256 - получите заодно уникальный ключ для юзера. Можете передавать его партнёрам или писать на стене. Однако, возможна ситуация когда вы немного исправили процедуру нормализации и хэширование для уже существующих email в базе будет выдавать другой ключ. Впрочем, и без хэширования нормализованный email в базе может измениться.
По теме проверки email - как обычно, на древнем StackOverflow сохранились сокровища с примерами вроде этого. Все понимают, что надо где-то знать меру, но не все знают про эти дополнительные фичи вроде той же субадресации (RFC5233).
Однако, это уже дополнительная фича, которая может не поддерживаться почтовым сервером. Даже автор статьи в примере приводит только gmail. Однако, плюс (и минус, а также может быть и решетка #) для этого используют почти все крупные почтовые сервисы. Фича с точками - только у gmail AFAIK, но ещё могут быть корпоративные домены, которые хостятся на gmail, а так же более мелкие сервисы. Просто так нормализация - довольно непростой процесс.
kasthack_phoenix
22.07.2025 21:42Можете передавать его партнёрам
Партнеры хотят сырой имейл, а не ID / хэш.
Я расскажу страшную историю: у нас недавно отвалилась интеграция с одним из партнеров. Они интегрируются по стандартизированному SOAP, принимая не менее стандартизированный MISMO-документ, для которого есть DTD, по которому можно собрать десериализацию с нулём ручного кода. Казалось бы, что может пойти не так?
Выяснилось, что у партнёра не реализован SOAP на самом деле — они принимают сырое тело SOAP-запроса и парсят через поиск подстрок, не используя даже стандартный XML-парсер. Предсказуемо, оно развалилось, когда мы им новое поле, включённое в стандарт, стали отправлять.
Именно из-за таких историй надо бить линейкой по пальцам за попытки разрешить пользователям использовать полный стадарт RFC на почты, телефоны по E.164 с поддержкой допномеров, юникод в полях, которые для него не предусмотрены и подобного — даже самая современная система опирается на огромный карточный домик существующего легаси из говна и палок, который разваливается, если попытаться затолкать в него хоть что-то нестандартное.
baldr
22.07.2025 21:42Ну так-то отвалиться может что угодно. Они могут вообще распечатывать ваш xml и прогонять через OCR, а потом диктовать слепому наборщику текстов по телефону со стадиона - и вы ничего с этим не сделаете.
А про SOAP - ну так-то там много стандартов наверчено вокруг. Я года 4 назад честно пытался начать работать с сервисом, который в SOAP использует ws-addressing и кучу подписей в документе и в транспорте. В итоге оказалось, что ни в одной Python библиотеке просто не поддерживается одна из особенностей - что-то там не подписывалось правильно и все мои попытки самому починить ни к чему не привели. В итоге, после трёх месяцев я нагуглил у собратьев по несчастью что в php это как-то работает и всё закончилось костылём где я из python вызываю php для отправки файла.
А этот SOAP-сервис, который сначала был стройно разбит на несколько wsdl и xsd файликов уже через пару лет превратился в сборище разных версий этих xsd, которые ссылаются друг на друга в хаотичном порядке.
Простите, наболело.
kasthack_phoenix
22.07.2025 21:42Они могут вообще распечатывать ваш xml и прогонять через OCR
Вы не поверите, но такое тоже есть. У нас один из партнёров не всегда консистентные данные между XML и PDF-кой договора присылает, так что мы парсим PDF для валидации, и ничего, не жужжим. Причём эта контора активами на триллионы долларов управляет и не работать с ними нереально — когда ОП пишет про прошаренных чуваков, отказывающихся от услуг, когда видят валидацию не по RFC, сразу ясно, что в серьёзном бизнесе не работал.
Ну так-то отвалиться может что угодно.
Может, так что не надо обострять ситуацию, собирая эджкейсы.
R3B3LL10N
22.07.2025 21:42Дело в том, что для шарящих ребят кривая валидация - это как красная тряпка
А нужны ли такие шарящие ребята? Они умные, скорее всего. На дарк паттерны не ведутся, на спам не отвечают, адблоком пользуются, ещё и ПД свои стараются не светить.
Для современных корпораций это они красная тряпка. Пусть лучше идут шарить в другое место, главное чтоб Мариша с ноготочков смогла зарегаться и её можно было бы окучить.
kbones Автор
22.07.2025 21:42У бизнеса два выбора: делать сервис для «Мариши» или для «гиков».
Но фишка в том, что «гик» - это как ресторанный критик. Да, он привередливый и на скидки не ведется. Но если уж ты смог накормить его так, что он остался доволен, то «Маришка» точно не отравится и будет в восторге.
А вот сервис, сделанный только для «Мариши», рано или поздно сломается, и пострадает именно она.
Так что «шарящие ребята» - это не проблема. Это бесплатный отдел качества, который работает на всех.
urvanov
22.07.2025 21:42Особо упоротые ещё могут и длину e-mail ограничить.
GDragon
22.07.2025 21:42ахахаха
я видел 2 варианта такого упорантства
1) ограничение минимальной длины домена ("такого домена как @ya.ru не существует!")
2) ограничение минимальной длины адреса ("никакого 1@личныйдомен тебе пёс!")
JBFW
22.07.2025 21:42Или ограничение на номер телефона:
903 0хх хх хх мы не понимаем, потому что не может номер на 0 начинаться...
chrooter
22.07.2025 21:42удивительно что ты поднял эту проблему только сейчас, повальное тупение разработчиков началась лет 15..20 назад, и по бессилию перестал пользовать тегирование и забыл уже и думать об этом. но тему нужно поднять выше
0xC0CAC01A
22.07.2025 21:42Не удивлюсь, если скоро появятся плагины для браузера, каким-либо образом заставляющие кривой валидатор на фронтэнде вернуть true. Ведь ребятки, не умеющие валидировать емейлы, не считают проблемой делать валидацию во фронтэнде.
urvanov
22.07.2025 21:42У браузеров уже есть механизм для проверки e-mail так-то:
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/email
TimurZhoraev
22.07.2025 21:42Потенциально валидацию можно сделать через сертификаты и взаимные печеньки (чтобы исключить ддос-ы) условных доверенных центров (юзер всё равно где-то проходит двойную аутентификацию в крупных структурах а-ля гуглы и прочие Госуслуги), когда фронтенд или бэкенд может выполнить нечто вроде "whois email" на сервер а тот ответит валиден этот юзер или нет как настоящее физлицо. Тогда проблема парсинга отпадает сама собой.
artptr86
22.07.2025 21:42До валидации на сервере всё равно скорее всего будет сделана валидация по формату, чтобы всякий мусорный ввод отбрасывать.
xi-tauw
22.07.2025 21:42На всякий случай: '_' (состоящий из трех символов) валидный username для почты.
urvanov
22.07.2025 21:42А кто-нибудь в курсе, почему стандартный input type = email никто не использует?
kasthack_phoenix
22.07.2025 21:42Как раз потому, что соответствие RFC — это не желаемый эффект и предпочтительные правила валидации жёстче из-за сторонних ограничений.
root@localhost— валидный имейл по RFC, но пропускать его вы не хотите почти никогда.
santjagocorkez
22.07.2025 21:42Ребята, вы теряете пользователей, которые хотят запретить вам спамить! Не делайте так!
Ещё из недавнего: совсем недавно на линкаче ржали с валидации ящика:
def is_valid(input): if "@" not in input: return False if "." not in input: return False return Trueimgonna.spam@you тут же передал привет.
JBFW
22.07.2025 21:42Это может объясняться просто другой логикой валидации: вы ввели почту - нам пофиг, достаточно если это будет похоже на почту, а не на номер телефона, к примеру.
Соответственно, "собака" есть? Точка хоть одна есть? Сойдёт, не получите ответ - ваша проблема.
vladkorotnev
22.07.2025 21:42Gmail игнорирует точки в адресах.
my.user@gmail.com,myuser@gmail.comиm.y.u.s.e.r@gmail.com— это один и тот же ящик. Блокировать точки вы будете?Что-то сколько раз ни пытался этим трюком воспользоваться, всё время письмо «в молоко» уходило, это точно работает?
Rubilnik
22.07.2025 21:42На яндекс mail@yandex.ru и mail@ya.ru - одно и то же, на заметку)
Ещё у нелюбимого всеми mail.ru есть возможность создания дополнительных адресов.
KEugene
22.07.2025 21:42Gmail игнорирует точки в адресах
Подождите, подождите. Это как? Мой гуглоаккаунт содержит точки. Когда я его делал, то нужное мне имя было занято. Я добавил точки, как разделители, и все получилось. То есть вы хотите сказать, что имя1.имя2@gmail.com и имя1имя2@gmail.com - одно и то же? Нет, не могет такого быть. Это же означает, что я делю свою почту с каким-то неведомым чуваком. Стоп, речь идет не просто про почту. Это совместный гуглоаккаунт! "Да нет, бред какой-то..."©
urvanov
22.07.2025 21:42Интересная теория. Может, тот чувак удивляется, куда девается часть его почты, а он у вас в спаме.
Abyss777
22.07.2025 21:42Конечно, давно интернет полон жалоб https://www.reddit.com/r/GMail/comments/jsmcmo/gmail_dots_apparently_do_matter_i_keep_getting/
Но гуглу пофиг. Там какого спамера наняли, который во все жалобы копипастит одно и то же.
Paultino
22.07.2025 21:42Да, это так. Я получаю письма для двух человек которые поставили точку в адресе ящика.
opusmode
22.07.2025 21:42я 20 лет пльзуюсь почтой и никогда не использовал +. Порядок во входящих прекрасно можно организовать и в UI.
Притом скорее 99% моих знакомых про плюс и н езнает.
Не говоря о том, что почта это атавизм и хорошо бы от неё отказываться.
ТАк что думаю coolservice переживёт без пары пользователей, которые очень захотели поюзать стандарты
alexs963
22.07.2025 21:42Не говоря о том, что почта это атавизм и хорошо бы от неё отказываться.
Чем предлагаете заменить?
Vitaly83vvp
22.07.2025 21:42Не согласен. Ниже опишу своё мнение, которое я никому не навязываю.
"+" я пользуюсь давно и это удобно при сортировке почты. про "." не знал, но теперь знаю. про "___" - это занимательно.
почта удобна, особенно, когда нужно найти важную переписку. мессенджеры тут и рядом не стояли.
предпочитаю почтовые клиенты, а не online, т.к. доступ к online могу закрыть в любой момент (ну, или сама почтовая система перестанет существовать), а письма на диске останутся.
если что, с "никогда такого не произойдёт" я уже несколько раз сталкивался.не могу не вспомнить про RSS. я его до сих пор использую, если сайты поддерживают этот вариант (и, кстати, опять же, через почтовый клиент).
к сожалению их становится меньше - его тоже считают атавизмом.
проще пролистать сообщения из RSS, чем на сайте листать ленту. так я с большей вероятностью найду понравившийся мне материал.
к счастью, habr пока поддерживает его и буду надеяться, что поддержка не прекратится.
titulusdesiderio
22.07.2025 21:42Вы, друг мой, гик, как и я. Я так же зашёл в эту статью из RSS. Пользуюсь
+и thunderbird.Но нас таких на уровне погрешности. Никакого значения для бизнеса мы не имеем.
pnmv
22.07.2025 21:42Замечательная функция, о которой я не знал.
Попробовал отправить себе на gmail пару писем с этими плюсами.
ожидание: письмо с "плюсовым тегом", автоиатически, падает в соответствующую папку.
реальность: все эти плюсы лежат во входящих и нужно настраивать дополнительные правила сортировки или применять "поиск в почте".
Думал, сначала, что так себя ведёт почтовый клиент на телефоне, но и в компьютерном браузере вижу такое же поведение.
anzay911
22.07.2025 21:42Правильное решение: перед сохранением в базу данных email нужно нормализовать — привести к каноническому виду.
"Проблема" создана на стороне пользователя. Он же и знает как её решать.
kvazimoda24
22.07.2025 21:42Когда у тебя свой домен, можно поднять на нём почту, и разделять сервисы по локальной части email'а. Но даже так довольно часто сталкиваешься с проблемами:
Список разрешённых доменов первого уровня, в котором например нет .pro
Жесткая привязка в gmail.com
Приложение, которое создано для использования в корпоративной среде, имеет ограничение на длинну домена и/или список разрешённых доменов первого уровня.
И вот на фоне таких проблем, неподдержка плюса уже не кажется проблемой.
Revertis
22.07.2025 21:42Пользуюсь почтой на своих доменах (но из старого набора) уже лет 15.
Но при регистрациях использую только то, что автор поста использовал бы после плюса.
То есть, при регистрации, например, на нетфликсе - netflix@mydomain.tld
Такой подход идеален.
Kurochkin
22.07.2025 21:42А что делаете при утечках, коллега? (Использую ту же схему, и вот уже много лет на adobe@мойдомен и пару других мне пишут нигерийские принцы)
Revertis
22.07.2025 21:42Если честно, ничего пока. На такие адреса идёт спам только на адрес, который знало только издательство Питер. Спамодав на сервере хороший (rspamd), и такие письма пробиваются где-то раз в два года.
Nansch
22.07.2025 21:42чтобы сайт не терял пользователей из-за тега после плюса, его, этот +тег сервису надо опускать для любых важных целей, типа авторизации в сервисе идентификации пользователя, отправки платёжных документов, а вот для отсылки рекламы самое то и пользователь рад, что тегирование работает. То есть сервис должен понимать, что после плюса это не часть адреса, а просто декоративный тег для удобства пользователя.
UPD. Получается, если сервисы начнут правильно разбирать мыло и узнавать +тег, то идея использовать +тег для защиты от спама и поиска того кто слил мыло снова накроется.
Ivan_shev
22.07.2025 21:42Как то я при регистрации на сайте к email добавил +SiteName и все было успешно пока я не решил авторизоваться, оказалось окно email имеет длину ввода символов больше при регистрации чем при авторизации, и я бл... попал в этот промежуток, мне писали что email слишком большой, ПРИ АВТОРИЗАЦИИ!!!. Я уже точно не помню, но больше я не мог использовать эту почту на том сайте.
Vitaly83vvp
22.07.2025 21:42Тут нужно подумать - если на этом этапе такие косяки, то стоит ли пользоваться этой системой?
askharitonov
22.07.2025 21:42if '@gmail.com' not in email and '@googlemail.com' not in email:
А если кто-то сделает адрес в домене вроде gmail.com.example.ru?
TimurZhoraev
22.07.2025 21:42Вообще говоря подобного рода стандарты появились, когда что-то из курилок Bell Labs в 70-е было уже де-факто, а потом оформилось де-юре, это же касается и тех самых языков программирования. Поэтому простое следование означает, что потенциально останется аудитория, которая знает как сделать тонкий клиент Радио-86РК программатором ЭПСН-25.
Не сегодня так завтра появится Undecillion co. которая скажет что в духе нашей команды теперь в почте и домене могут быть пробелы-смайлики и полный набор Unicode. А наше дополнение позволяет резольвить любое поле аутентификации в наш SunnyFlare с бонусной годовой подпиской как API с функционалом почты, поэтому обходитесь без назойливой @. Браузер WaterDog наконец-то поддерживает сплит-поля в одном теге где отдельно вводится идентификатор, субидентификатор и домен, равно как нормально парсятся даты, время и часовые пояса. Поэтому, лучше следовать самым современным и актуальным нововведениям и сосредоточиться на разделении потоков потенциальных ошибок и ущерба от них на классы по времени восстановления с точки зрения безопасности.Есть ещё отдельное направление List-Request со знаком минус и прочая автоматизация по образу Git
Format-X22
22.07.2025 21:42Так пробелы и смайлики могут быть. Стандарт почты поддерживает любую строку, если её экранировать кавычками в начале и конце. Просто такую дичь вообще почти никто не использует, но она возможна.
А ещё у меня когда-то была почта на домене @фирмы.онлайн , прям по-русски, да. И письма ходили… но не везде.
Krypt
22.07.2025 21:42Правильное решение: перед сохранением в базу данных email нужно нормализовать — привести к каноническому виду.
Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
Исправьте свой RegEx!
TimurZhoraev
22.07.2025 21:42Проблема возникла ввиду того, что адрес почты это объект и практически имеет поведение, то есть имя содержит дополнительные элементы-теги, влияющие на поведение сервера. Исторически получилось так что Username == Email, поэтому конечный пользователь а-ля тётя Юля (для многотысячной посещаемости там 99 таких, включая ботов) не будет утруждать себя чтением RFC. Это скорее нужно администраторам и разработчикам. Особенно там где сложилось так что почта используется в режиме мессенджера и автоматизации рассылки как mailing lists, снабжая адресата суффиксами +- итд. По сути сейчас идёт трансформация почты в чат, поэтому, скорее всего, автоматизацию из имён скорее всего уберут или оставят как unsupported.
Krypt
22.07.2025 21:42Мой коммент скорее про то, что у email нет канонического вида. У каждого сервера свои правила - тот же гугл - наверное единственный, кто точку в адресе игнорирует.
А по поводу нормализации для ДБ - я, как пользаватель, ожидаю чтоuser+test1@gmail.comиuser+test2@gmail.comкак раз два разных адреса с точки зрения сервиса. Ну и как бы email-адреса авторизации скрывать принято.
А если сервис боится, что пользователь зарегистрирует два аккаунта, то ему придётся с этим смериться. Пользователь может создать второй ящик.TimurZhoraev
22.07.2025 21:42Всё верно, просто с точки зрения пользователя, у которого есть суффиксы, может возникнуть неопределённое поведение, он ждёт от сервера обработку запроса на основании имени. Другой вопрос зачем он этот суффикс использует для юзернейма, регистрации итд вне почтового клиента. То есть вне рамок SMTP канонического вида нет и все адреса хоть с + хоть с - являются уникальными и независимыми. Но если сайт предполагает взаимодействие с именем почты как с объектом и обработкой тегов то он уже должен хранить его в приведённом виде. Это скорее вопрос соглашений и на него однозначного ответа нет.
Wesha
22.07.2025 21:42Мой коммент скорее про то, что у email нет канонического вида.
Ваистену так
...благодаря длинной череде проблем, вызванных промежуточными хостами, пытавшимися оптимизировать передачу путём изменения их [адресов], локальная часть ДОЛЖНА быть интерпретирована (и ей должен быть назначен семантический смысл) исключительно сервером, указанным в доменной части адреса.
Vitaly83vvp
22.07.2025 21:42Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
Тут имеется в виду сохранять нормализованный вариант во вспомогательном поле. Основное поле, используемое для авторизации, отправки сообщений, будет содержать неизменённый email. И использовать его только для проверки дубликатов.
Krypt
22.07.2025 21:42А зачем их вообще проверять? Я, как пользователь, ожидаю, что сервис их будет обрабатывать именно как два разных ящика.
Vitaly83vvp
22.07.2025 21:42Вы знаете, этот подход тоже имеет место быть. Тут всё зависит от логики системы. Если системе нужны "уникальный адреса", то они будут фильтровать. Если системе это не важно (и пользователи не злоупотребляют этим - а, злоупотребление и есть основная причина добавления проверки), то она будет работать со всеми адресами.
Кстати, в одной системе я, как раз, тоже использую "+" для поддержки двух аккаунтов - не хотел заводить новую почту. Да, и для новой почты становится обязательным новый номер телефона.
TimurZhoraev
22.07.2025 21:42Вообще говоря, это уже задача фронтенда и, по-хорошему, должно появляться всплывающее второе поле при наличии любых суффиксов и галочка для пользователя "считать имя составным" если это критически важно для механизма взаимодействия сайта на основе почты (рассылка, уведомления итд). То есть поддержка стандарта уже реализуется на уровне интерфейса, так как иными методами указать явно это не получится. В этом случае сайт для аутентификации использует каноническое представление.
Эта боль - неотъемлемый атрибут всех спецификаций с поведением. Даже ASCII с его перевод строки и возврат каретки, звонок Bell или управляющие последовательности для телетайпа-принтера. По аналогии можно заставить обычным текстом условного имени пользователя пропищать динамик или выплюнуть бумагу при печати заголовка.Krypt
22.07.2025 21:42Я не говорю что такого не существует или не должно существовать, но я ни разу не видел сервиса который мы давал имя пользователя на основе email. Это всегда заполняемое вручную поле. И если я ввёл адрес с суффиксом - это значит я хочу получать корреспонденцию от сервиса именно на имя с суффиксом.
Эта боль - неотъемлемый атрибут всех спецификаций с поведением.
Сохраните email как его ввёл пользователь и не пытайтесь его обработать:
https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.11Consequently, 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.
TimurZhoraev
22.07.2025 21:42Вы абсолютно правы с точки зрения формального подхода 1 поле = 1 данное без разночтения. С другой стороны есть приверженцы обрядов. Вообщем вывод напрашивается сам собой и носит по всей видимости чисто административный характер - писать свои предложения в
СпортлотоRFC. "Подать жалобу. Коллективную (С)" Чтобы уже привели всё в нормативы 21 века.В принципе так и делается если существует некая точка которая мешает ввиду того что когда-то она была принята с аргументом нам жалко 2 байта на дату, а потом все бегают с проблемой 2000-го года. Хотя грядёт ещё 2^32 в 2038 году.
Это должна быть совместная работа W3C, IEEE, RFC итд итп, но там по всей видимости... Линус прав. Основным мейнтейнерам этого дела уже почти за 70. Поэтому новые разработчики вынуждены будут учиться по тем шаблонам которые закреплены и забетонированы как стандарт пока сами не предложат новое.
PS Если кому-нибудь, вытащенному из модемных 90-х сказать что в браузере в строку адреса можно будет сразу писать поисковый запрос вместо URL вида http://www.... то 8-[
Wesha
22.07.2025 21:42Если кому-нибудь, вытащенному из модемных 90-х сказать что в браузере в строку адреса можно будет сразу писать поисковый запрос вместо URL вида http://www.... то 8-[
Если кому‑то, вытащенному из 2010-х, сказать что в браузере в строку адреса можно сразу написать URL вида http://mail.ru вместо того, чтобы печатать «mail.ru» в поиске тындекса...
baldr
22.07.2025 21:42Неправильное. RFC (не вспомню какой, правда) запрещает преобразование email адреса где-либо, кроме сервера-владельца. Если вы хотите следовать RFC - вы должны принять адрес как его вам дали.
А как же регистр? Юзер зарегистрировался как "vasya@gmail.com" и пытается зайти с "Vasya@gmail.com" - тоже не надо преобразовывать?
unreal_undead2
22.07.2025 21:42Вроде сейчас обычная практика при логине по email локальный пароль не заводить, для авторизации присылать одноразовый пин на почту - так что ничего преобразовывать не надо.
baldr
22.07.2025 21:42Так а пользователя-то как находить в базе при логине? Это же один аккаунт. Пароль тут совсем не при чём. Вопрос в том - как хранить email в базе.
unreal_undead2
22.07.2025 21:42Хранить в базе - точно без преобразований, но сравнение на равенство с учётом эквивалентности по RFC.
И в теории локальная часть адреса case sensitive, просто некоторые (сейчас, видимо, подавляющее большинство) почтовые сервера раскидывают письма по пользователям без учёта регистра.
baldr
22.07.2025 21:42Ну тогда мы снова вступаем на скользкую дорожку - разные ли пользователи "Vasya" и "vasya"? Тут проблема с плюсом уже - частный случай.
Но я ни разу не встречал сервиса где такое разрешалось. Наверное и правильно.
unreal_undead2
22.07.2025 21:42Правильнее всё таки следовать RFC.
TimurZhoraev
22.07.2025 21:42Всё верно, просто если стандарт имеет, как было любезно указано выше участником Krypt, строки "due to a long history of problems", это означает что он частично является костылём к го́ре или горе́ легаси. Поэтому, будет соблазн однозначно идентифицировать пользователя, инкапсулировав адрес в промежуточное представление, например UUID_имя@домен или даже Base64_имя@домен. А имя может содержать хоть байткод/анекдот. То есть появятся некие сервисы которые завернут SMTP в более высокоуровневые конструкции актуальные в настоящее время. В эту же копилку номер телефона == мейл.
Krypt
22.07.2025 21:42То есть в случае для входа используется именно пара email/пароль?
Логика говорит, что наверное стоит спрашивать email как он был введён пользователем изначально. Пользователь знал, что он делал. Наверное.
Кроме, может быть, таки регистра, потому что многие считают и ожидают что email регистронезависим. А если нужно отправить email - использовать адрес в точности как его ввёл пользователь. Если вы при регистрации отправляли письмо и пользователь подтвердил получение - то вы уже знаете, что письмо дойдёт.
Krypt
22.07.2025 21:42Не надо. И таки да, по RFC это два разных email:
https://datatracker.ietf.org/doc/html/rfc5321#section-2.4Therefore, 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".
askharitonov
22.07.2025 21:42С практической точки зрения, если адрес электронной почты сильно отличается от обычных адресов, то это скорее попытка взлома, а не реальная необходимость использования email нетипичного вида, хотя и формально корректного.
titulusdesiderio
22.07.2025 21:42ты должен был бороться со злом, а не примкнуть к нему!
ТС озвучил очень неприятный для гиков баг - за это конечно же
+. Но предложил решить его ужаснейшим образом через нормализацию - за это точно-.Что те кто не поддерживают регистрацию с плюсами, что те кто не поддерживают регистрацию разных аккаунтов на алиасы - ограничивают меня как пользователя в правах. Предпочитаю обходить такие сайты стороной
unreal_undead2
22.07.2025 21:42Идея гениальна в своей простоте: почтовый сервер, получая письмо на адрес
localpart+tag@domain.com, должен доставить его в ящикlocalpart@domain.com, проигнорировав+tag.А чем это принципиально отличается от обычных комментариев в email адресе?
IgnatF
22.07.2025 21:42Тут разработчик может просто сделать два поля. Одно логин с плюсом, второе без него. При регистрации отбрасывать все то, что за плюсом и сравнивать по второму полю. Если уже запись есть отправлять соответствующие предупреждение любителям мультиакков.
Но это всю систему ломать нужно. Про этот плюс может только один продвинутый из 10 000 знает. Лично я, вечером добавлю такой момент в свои скрипты регистрации.
lehha
22.07.2025 21:42Вы забыли добавить весь алфавит UNICODE в регулярное выражение. Иероглифы там же.
Универсальное принятие, которое играет из колонок уже несколько лет, планомерно просит все сервисы и приложения принимать введенную почту как есть. Вы можете попытаться провести её проверку многоуровневыми проверками вплоть до обращения к DNS для проверки валидности указанного домена (проверка@пример.испытание был валидным адресом и домен резолвился), но никогда не сможете поддерживать в актуальности эту проверку. Одна из рекомендаций - использовать публичные библиотеки по валидации. Но учитывая нашу лень и прибивание гвоздями версии библиотек, тоже будут ошибки.
В дискуссии с авторами этого всего было выдвинуто предложение - просто попробуйте доставить туда письмо. Если дошло (не вернулось или кликнули по ссылке и подтвердили адрес) - адрес валидный.
メール@例.テスト
t38c3j
22.07.2025 21:42У меня был свой почтовый сервер и алиас я настроил через точку, так раз чтоб такого избежать, но вылезла другая проблема на некоторых сервисах, домен верхнего уровня .email считают невалидным, мол больше 3 символов ))
Reternos
22.07.2025 21:42Gmail игнорирует точки в адресах
У меня всю жизнь gmail аккаунт содержал точку (типо ник1.ник2@gmail.com) сейчас попробовал зарегать акк без точки и всë получилось (по типу ник1ник2@gmail.com)
А за плюсы спасибо буду пользоваться (правдо на сайтах с нормализацией в теории работать не должно)
isden
22.07.2025 21:42Кмк самая правильная валидация - это пускать все типа
<что-то>@<что-то>и пытаться либо начать SMTP хендшейк, либо реально отправить письмо со ссылкой для активации.А по поводу нормализации - что ввели то и храним (после strip && lowercase).
Krypt
22.07.2025 21:42Нельзя lowercase. email case sensitive в общем случае.
isden
22.07.2025 21:42
Krypt
22.07.2025 21:42
"Не приветствуется" и "никогда не случится" - это разные вещи.
Лично я исхожу из принципа, что нужно следовать пессимистичному сценарию:
- С точки зрения сервиса отправляющего почту - что адреса должны быть именно в той форме, в которой адрес дал ему пользователь, иначе почтовый сервис не доставит письмо.
- С точки зрения почтового сервера - что сервис отправляющий почту будет творить всякую ересь вроде попытки "канонизировать" адрес только по одному сервису известному принципу.isden
22.07.2025 21:42А я лично исхожу из соображений совместимости. Большинство крупных сервисов case-insensitive. У себя я тоже так сделал.
Я вот даже не вспомню сходу у кого case-sensitive.
Krypt
22.07.2025 21:42Аналогично. Я не говорю что вы должны делать case sensitive на почтовом сервере. В rfc написано сервер может делать с ними что ему вздумается, пока он следует корректному синтаксису адресов. Хоть всю почту в один ящик скинуть.
Вопрос именно в том, как сторонние сервисы воспринимают адрес получателя. Для максимальной совместимости "нормализовать" (к чему?) и менять регистр нельзя.isden
22.07.2025 21:42Я немного потестил ms/gmail - в целом им пофиг на регистр. При отправке, например to: John@doe.com, cc: jOhn@doe.com уходит реально только первое, cc и все остальные одинаковые отбрасываются.
По опыту общения с разными пользователями крупных сервисов они тоже не различают кейс, вполне могут написать свой адрес как JohnDoe@gmail.com, AnotherJohn@gmail.com, ANOTHERJOHN@GMAIL.COM, и т.п.
Так что логично для большей совместимости со всеми у себя исключить возможность заведения одинаковых адресов, отличающихся только регистром, и обрабатывать без его учета.
Tomasina
22.07.2025 21:42Дико плюсую. Постоянно использую плюсик при регистрации, именно как метку для контроля утечки спама, и бесит что многие современные сайты (включая солидные конторы) отказываются его принимать.
avost
22.07.2025 21:42О! Как раз на днях пытался зарегаться на какой-то ивент крутейшей (по их словам) сетевой компании selectel мылом с плюсиком. Не пущщает. Из вредности написал в поддержку. Поддержка здорового человека сказала бы, - погоди, ща починим. - Но поддержка курящего селектела с гордостью ответила, - да, мы таких
уродовне регаем и регать не будем!
Причём на каком-то другом соседнем их же сервисе мыло с плючиком без проблем пролезло.
Arenoros
22.07.2025 21:42я искренне не понимаю на кой проверять почту регулярками, чем не устраивает проверка наличия просто @ и даже в ней то смысла не то чтоб много
agorshkov23
А что мешает при утечке нормализовать емейлы, и тогда невозможно будет от кого произошёл слив.
0xC0CAC01A
Вот именно, фигня этот ваш плюс
kbones Автор
Вопрос хороший, конечно, никто не мешает им почистить базу.
Но фишка в том, что почти все спамеры — дико ленивые ребята. Они гоняют гигантские сырые списки, и им просто лень заморачиваться с какой-то там «нормализацией». Главное быстро заспамить
И тут два варианта:
Спамер умный и почистил базу, ну окей, спам упадет в твой основной ящик. Ситуация ровно та же, как если бы ты не использовал тег. Ты ничего не потерял.
Спамер — лентяй, а он почти всегда лентяй и ты сразу видишь, кто слил твою почту.
Так что «плюс» в почте — это не защита от всех проблем, она сработает не на профи-взломщика, а на обычную массовку.
agorshkov23
Но с другой стороны, если везде указывать плюс, то если пришло письмо без плюса, то потенциально это спам :)
kbones Автор
Ну да))) Это и есть продвинутый уровень.
Основной ящик держишь только для своих и банков, а для всего остального мира - почту с "+"
В итоге всё, что прилетает на «голый» адрес без тега, с вероятностью 99% спам. По сути обратный фильтр.
kapany3
Часто после оформления карты в банке спам и начинает лететь на почту/телефон
urvanov
Так каждый банк теперь заодно ещё и маркетплейс, и страховая компания, и кофейня, и брокер, авиабилеты продаёт. Ну и ваш номер с почтой тоже всем сливает направо и налево, разумеется.
ArtyomOchkin
Это точно. Зарегался в том году в тинькоффе, так вот, ровно с тех времён на мой основной email Яндекс почты как из рога изобилия стал сыпаться спам от всевозможных mail@server.shop
Скрин типичного спама (благо почтовая программа автоматически кладёт это в папку Спам)
AVX
О! Точно так и мне сыпется. Думаю, адреса отправителя поддельные, у меня другие там.
При этом я сам у них не регистрировался, но был инцидент, когда пытались на меня ИП оформить и счёт там открыть, присылали ссылки, типа просто что-то проверить, а по факту там оставалось 1 действие до завершения регистрации. ИП не открыли, несколько раз я им звонил и писал и ругался, а вот через какое-то время понеслось с таким спамом.
LF69ssop
Зачем для банков делать исключение?
CitizenOfDreams
И делаешь что?
randomsimplenumber
Наверное в black list добавляешь
с гордостью.Не помню, когда последний раз видел спам в почте. Спамодав достаточно успешно его детектит.
R3B3LL10N
Всё так. Я иногда залажу в спам, посмотреть что там новое разводилы придумали. Так так всё шаблонно - рандомный адрес отправки с какого-то крупного сервиса, в заголовке какая-то хрень типа "Предложение работы. Вас пригласили на интервью" и в теле абсолютно рандомная хрень из популярных слов, которая к заголовку даже отношения не имеет.
Интересно, зачем они вообще стараются? Очевидно что подобное не прокатит. Современный спамодав скорее зарежет по подозрению что-то ценное чем пропустит их высеры без фантазии.
Kurochkin
Думал об этом недавно... Предположу, что в каких-то странах (Азии/Африки) население массово использует местные сервисы, которые спам не так хорошо ловят. Там наверное и нигерийские письма ещё водятся.
mikhaylovali
вот именно, что ленивые и как правило не заморачиваются с такими мелочами, поэтому использовать всё же не совсем бесполезно. Ровно как и добавить пару запятых, что бы сломать базу паролей в чьём-то эксельчике
TerrorDroid
Лень мешает. Многократно ловил источники слива почты через этот трюк с плюсом. Никто даже не парится нрмализацию делать т.к. источники почты по-умолчанию считаются уже нормализованными.