Ваш сайт теряет пользователей прямо сейчас. Виноват один символ: '+' в email

Привет, Хабр! Представьте ситуацию: вы нашли крутой сервис, регистрируетесь, вводите свой email [e-mail] (ведь вы, как и я, любите порядок во входящих) и… получаете ошибку «Некорректный email». Знакомо? Уверен, что да.

Каждый раз, когда я сталкиваюсь с таким, у меня дергается глаз. Это не просто мелкий баг. Это симптом глубокой проблемы в подходе к разработке и непонимания базовых стандартов. Давайте раз и навсегда разберемся, почему сервисы не принимают почту с «плюсом», почему это плохо для бизнеса и, главное, как это исправить.

Как должно работать: магия субадресации по RFC 5322

Для начала — немного теории. Существует стандарт RFC 5322, который описывает формат электронных почтовых адресов. И этот стандарт черным по белому разрешает использование символа + в локальной части адреса (до символа @).

Эта фича называется субадресация (sub-addressing), или "plus addressing".

Идея гениальна в своей простоте: почтовый сервер, получая письмо на адрес [e-mail], должен доставить его в ящик [e-mail], проигнорировав +tag.

Пример:

Все письма, отправленные на адреса:

• [e-mail]

• [e-mail]

• [e-mail]

...придут в один ящик: [e-mail].

Это невероятно удобно. Пользователи могут:

1. Автоматически фильтровать входящие. Настроил правило в почтовом клиенте — и все письма с тегом +work падают в папку «Работа».

2. Отслеживать спам и утечки. Зарегистрировался на сайте super-shop.com с почтой [e-mail]. Если на этот адрес вдруг повалится спам от «Рога и копыта», вы точно знаете, кто слил вашу базу.

Эту фичу поддерживают все гиганты: 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 аккаунтов на одну почту и абузить наши промокоды для новых пользователей!»

• Почему эта логика порочна:

  1. Gmail-хак с точками: Gmail игнорирует точки в адресах. [e-mail], [e-mail] и [e-mail] — это один и тот же ящик. Блокировать точки вы будете?

  2. Временные почты: Существуют десятки сервисов временных email, которые решают задачу абуза гораздо эффективнее.

  3. Вы наказываете всех: Пытаясь остановить горстку мошенников, вы создаете проблемы для тысяч добросовестных клиентов. Это все равно что заварить все двери в здании, потому что кто-то может войти без спроса.

Причина 4: Проблемы с уникальностью в БД

Это более тонкий момент. Представим, что ваш сервис разрешил регистрацию на [e-mail]. Что произойдет, если тот же пользователь попытается зарегистрироваться на [e-mail]?

С точки зрения системы, это два разных email. А с точки зрения пользователя — один. Если у вас в базе email является уникальным ключом, вы позволите создать два аккаунта, привязанных к одному реальному ящику. Это может привести к путанице с восстановлением пароля, подписками и т.д.

Правильное решение: перед сохранением в базу данных email нужно нормализовать — привести к каноническому виду.

# Пример нормализации на Python
def normalize_email(email):
    """
    Приводит email к каноническому виду для хранения в БД.
    normalize_email('[e-mail]') -> '[e-mail]'
    """
    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-инженеров:

1. Проверяйте это всегда. Добавьте в свой чек-лист регистрации/авторизации кейс с email, содержащим +.

2. Заводите баг-репорт правильно. Не пишите просто «не работает почта с плюсом».

   • Тема: «Форма регистрации не принимает валидные email-адреса с субадресацией (содержащие '+'), нарушая стандарт RFC 5322».

   • Обоснование: Укажите, что это блокирует регистрацию для большой группы пользователей Gmail/Outlook и вредит репутации продукта. Приложите ссылку на RFC.

   • Ожидаемый результат: Система должна успешно принимать и обрабатывать такие адреса.

Для разработчиков:

1. Исправьте свой RegEx! Вот более адекватный вариант, который пропускает + (но он не идеален, идеальный RegEx для email занимает страницы):

   // Простой, но уже лучше
   const betterEmailRegex = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/;
   

   Но лучше всего использовать проверенные библиотеки для валидации, а не писать свои велосипеды.

2. Внедрите нормализацию. Перед проверкой уникальности и сохранением в БД приводите email к каноническому виду. Это решит проблему с дублированием аккаунтов.

Для менеджеров продуктов:

Не отмахивайтесь от этого бага как от мелочи. Каждый пользователь, который не смог зарегистрироваться, — это ваша упущенная прибыль или потерянный лид. Инвестиции в исправление этой проблемы — это инвестиции в пользовательский опыт и рост вашей аудитории.

Заключение

Проблема с + в email — это классический пример того, как пренебрежение стандартами и фокус на сиюминутных задачах приводят к системным ошибкам, бьющим по бизнесу.

Давайте уважать наших пользователей и стандарты, на которых держится интернет. Откройте свой проект прямо сейчас и проверьте: а вы дружите с плюсами?

Спасибо за внимание! Делитесь в комментариях своим мнением :)