Привет, Хабр! Представьте ситуацию: вы нашли крутой сервис, регистрируетесь, вводите свой 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 — это классический пример того, как пренебрежение стандартами и фокус на сиюминутных задачах приводят к системным ошибкам, бьющим по бизнесу.
Давайте уважать наших пользователей и стандарты, на которых держится интернет. Откройте свой проект прямо сейчас и проверьте: а вы дружите с плюсами?
Спасибо за внимание! Делитесь в комментариях своим мнением :)
Комментарии (59)
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Потому что человек может быть в этот момент в отпуске, за границей.
Когда это делает бизнес - проблемы бизнеса, а когда таким балуются государственные службы - это трындец.
Плюс, в последнее время они начали блочить и адреса впн. И получается, ты из за границы не можешь ничего сделать.
И это я не о России, а об Израиле...
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, а так же более мелкие сервисы. Просто так нормализация - довольно непростой процесс.
urvanov
22.07.2025 21:42Особо упоротые ещё могут и длину e-mail ограничить.
GDragon
22.07.2025 21:42ахахаха
я видел 2 варианта такого упорантства
1) ограничение минимальной длины домена ("такого домена как @ya.ru не существует!")
2) ограничение минимальной длины адреса ("никакого 1@личныйдомен тебе пёс!")
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
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 тут же передал привет.
vladkorotnev
22.07.2025 21:42Gmail игнорирует точки в адресах.
my.user@gmail.com,myuser@gmail.comиm.y.u.s.e.r@gmail.com— это один и тот же ящик. Блокировать точки вы будете?Что-то сколько раз ни пытался этим трюком воспользоваться, всё время письмо «в молоко» уходило, это точно работает?
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 переживёт без пары пользователей, которые очень захотели поюзать стандарты
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
Приложение, которое создано для использования в корпоративной среде, имеет ограничение на длинну домена и/или список разрешённых доменов первого уровня.
И вот на фоне таких проблем, неподдержка плюса уже не кажется проблемой.
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
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 канонического вида нет и все адреса хоть с + хоть с - являются уникальными и независимыми. Но если сайт предполагает взаимодействие с именем почты как с объектом и обработкой тегов то он уже должен хранить его в приведённом виде. Это скорее вопрос соглашений и на него однозначного ответа нет.
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 или управляющие последовательности для телетайпа-принтера. По аналогии можно заставить обычным текстом условного имени пользователя пропищать динамик или выплюнуть бумагу при печати заголовка.
titulusdesiderio
22.07.2025 21:42ты должен был бороться со злом, а не примкнуть к нему!
ТС озвучил очень неприятный для гиков баг - за это конечно же
+. Но предложил решить его ужаснейшим образом через нормализацию - за это точно-.Что те кто не поддерживают регистрацию с плюсами, что те кто не поддерживают регистрацию разных аккаунтов на алиасы - ограничивают меня как пользователя в правах. Предпочитаю обходить такие сайты стороной
agorshkov23
А что мешает при утечке нормализовать емейлы, и тогда невозможно будет от кого произошёл слив.
0xC0CAC01A
Вот именно, фигня этот ваш плюс
kbones Автор
Вопрос хороший, конечно, никто не мешает им почистить базу.
Но фишка в том, что почти все спамеры — дико ленивые ребята. Они гоняют гигантские сырые списки, и им просто лень заморачиваться с какой-то там «нормализацией». Главное быстро заспамить
И тут два варианта:
Спамер умный и почистил базу, ну окей, спам упадет в твой основной ящик. Ситуация ровно та же, как если бы ты не использовал тег. Ты ничего не потерял.
Спамер — лентяй, а он почти всегда лентяй и ты сразу видишь, кто слил твою почту.
Так что «плюс» в почте — это не защита от всех проблем, она сработает не на профи-взломщика, а на обычную массовку.
agorshkov23
Но с другой стороны, если везде указывать плюс, то если пришло письмо без плюса, то потенциально это спам :)
kbones Автор
Ну да))) Это и есть продвинутый уровень.
Основной ящик держишь только для своих и банков, а для всего остального мира - почту с "+"
В итоге всё, что прилетает на «голый» адрес без тега, с вероятностью 99% спам. По сути обратный фильтр.
kapany3
Часто после оформления карты в банке спам и начинает лететь на почту/телефон
CitizenOfDreams
И делаешь что?
randomsimplenumber
Наверное в black list добавляешь
с гордостью.Не помню, когда последний раз видел спам в почте. Спамодав достаточно успешно его детектит.
TerrorDroid
Лень мешает. Многократно ловил источники слива почты через этот трюк с плюсом. Никто даже не парится нрмализацию делать т.к. источники почты по-умолчанию считаются уже нормализованными.