Плюс‑адресация в email: принимать +теги и безопасно дедупить

Почему +-теги создают проблемы при регистрациях

Многие реальные люди используют адреса вроде [email protected]. Часть +tag — это тег (его ещё называют subaddress). Многие провайдеры доставляют такие письма в тот же почтовый ящик, что и [email protected], но тег позволяет пометить, где именно был использован адрес.

Люди применяют теги по практическим причинам: фильтрация (правила, которые отправляют сообщения в папки), отслеживание (понять, кто слил или продал адрес), и разделение регистраций (чтобы каждый аккаунт выглядел как отдельный адрес). Особенно часто это встречается у пользователей Gmail и Fastmail.

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

Типичные ошибки:

• Отклонение адресов с +, хотя на них приходят письма.
• Логика дедупа, которая объединяет name+billing@... и name+personal@... в одного пользователя.
• Сбои при сбросе пароля и входе, потому что пользователь вводит ту версию с тегом, которую использовал при регистрации.
• Сломанное восстановление аккаунта, когда система со временем «нормализует» адрес по-разному.

Считайте плюс-адресацию вариантом форматирования, а не доказательством мошенничества. Принимайте адреса, на которые можно доставить почту, и выполняйте дедупинг только когда это действительно безопасно. Самое простое правило, которое предотвращает большинство проблем: сохраняйте оригинальный адрес точно так, как его ввёл пользователь, и (если нужен ключ для сравнения) создавайте отдельный ключ только для поиска/сравнения.

Если вы запускаете валидацию email (например, через сервис Verimail), проверка должна концентрироваться на досягаемости и сигналах риска, а не на наказании пользователей, которые полагаются на +-теги.

Плюс-адресация и subaddressing простыми словами

Плюс-адресация — это способ добавить тег к email без создания нового почтового ящика. Обычный шаблон — [email protected], где часть после + помогает пользователю пометить, где был использован адрес.

Email состоит из двух основных частей: локальной части и домена. В [email protected] name+tag — локальная часть, а example.com — домен.

Три понятия часто путают:

• Плюс-адресация (subaddressing): тег, добавленный в локальную часть, часто через +.
• Алиасы: дополнительные адреса, доставляемые в тот же ящик (например, sales@ и hello@), управляемые провайдером или владельцем домена.
• Пересылка: почта, отправленная на один адрес, автоматически перенаправляется на другой.

То, что считается «тем же самым ящиком», зависит от конфигурации принимающего провайдера и домена. Технически [email protected] и [email protected] — разные строки. Некоторые провайдеры доставляют и то, и другое в один ящик, но не все, и поведение может отличаться по доменам.

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

Пример: клиент использует [email protected] для рассылок и [email protected] для счетов. Если ваше приложение убирает +news и +billing, вы можете объединить разные намерения в один аккаунт и вызвать путаницу (и обращения в поддержку).

Где плюс-адресация работает, а где нет

Плюс-адресация распространена, но не универсальна. Многие крупные почтовые сервисы принимают адреса вроде [email protected] и доставляют их в тот же ящик, что и [email protected]. Но другие могут обрабатывать + иначе или не поддерживать его.

Важно понимать: правило устанавливает принимающий домен. Даже в одной компании разные домены могут иметь разные настройки маршрутизации почты. Жёсткое правило «+ всегда работает» или «+ никогда не работает» со временем начнёт блокировать реальных пользователей.

Вариации, которые вы увидите

Некоторые домены поддерживают + только для определённых почтовых ящиков. Некоторые допускают другие разделители. Некоторые конфигурации пересылают почту через системы, которые обрезают или переписывают части локальной части. Рассматривайте subaddressing как «возможно» — пока вы не проверили поведение домена.

Чего не стоит предполагать для всех доменов:

• Не удаляйте точки (jane.doe vs janedoe), если вы не уверены, что домен так ведёт себя.
• Не приводите локальную часть к нижнему регистру для всех доменов. Чувствительность к регистру редко встречается, но она разрешена стандартом.
• Не убирайте +tag для решения вопросов доставки (отправки писем пользователю).

Как справляться с неопределённостью, не ломая регистрации

Безопасный набор правил прост: принимайте адрес, который ввёл пользователь, проверьте его и храните точно так, как введено, для отправки. Если нужен дедуп-кейс, храните отдельное поле "нормализованное для сравнения".

Если кто-то регистрируется как [email protected], чтобы отфильтровать onboarding-письма, отклонение такого адреса приведёт к потере реального клиента. Перезапись в [email protected] может быть так же плоха — вы перестанете отправлять туда, куда пользователь ожидает.

Практический путь: принимайте адрес, затем выполняйте синтаксическую проверку и проверку настроек домена (включая MX-записи), и затем запускайте проверки на disposable и риск. API валидации, такой как Verimail, может подтвердить корректность формата и настройку домена, при этом вы сохраняете оригинальный адрес без изменений для доставки.

Что хранить: оригинальный email vs нормализованный

Храните то, что ввёл пользователь, и отправляйте именно на этот адрес. Люди используют теги для реальных задач (фильтрация чеков, разделение работы и личных регистраций), и переписывание адреса может нарушить доставку или усложнить поддержку, когда пользователь скажет: «Я регистрировался как [email protected]».

В то же время многие продукты хотят иметь второй ключ, который помогает находить дубликаты и поддерживать порядок. Именно сюда и идёт нормализация: в отдельное внутреннее поле, не в адрес для отправки.

Практическая модель данных содержит два поля с разными задачами:

• Email (оригинал): точный ввод, хранимый для отправки, отображения и аудита.
• Email key (нормализованный): консистентная форма, используемая для дедупа, поиска и совпадений.

Информацию о верификации храните отдельно. Валидация — это свойство адреса в конкретный момент времени. Храните статус (valid, risky, invalid), причину (например, отсутствует MX) и отметку времени.

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

Конкретный пример: сохраняйте [email protected] как оригинал, но держите ключ вроде [email protected] для совпадения. Письма по-прежнему попадут туда, куда ожидает пользователь, а ваша система увидит возможные дубликаты без переписывания адреса доставки.

Пошаговая стратегия безопасной нормализации для дедупинга

Принимайте реальные адреса (включая плюс-адресацию), одновременно замечая дубликаты через отдельный ключ, а не переписывая то, что ввёл пользователь.

Практический подход:

1. Обрежьте и очистите ввод. Удалите начальные и конечные пробелы. Отклоняйте управляющие символы (табуляции, переводы строк, нули), которые могут скрыть другой адрес или сломать логи и рассылки.

2. Запустите базовую проверку синтаксиса, но не запрещайте +. Валидная локальная часть может содержать + и другие символы. Сосредоточьтесь на явных ошибках: отсутствует @, пустые части или запрещённые пробелы.

3. Нормализуйте домен аккуратно. Приводите домен к нижнему регистру и нормализуйте последовательно. Если вы поддерживаете интернационализированные домены, конвертируйте их стандартным способом, чтобы exämple.com и его ASCII‑форма соответствовали одному домену.

4. Правила для локальной части применяйте только когда контролируете риск. Не удаляйте +tag глобально. Если вы хотите дедупить [email protected] с [email protected], делайте это только для доменов в явном белом списке, поведение которых вы проверили.

5. Создайте стабильный dedupe-ключ, оставив оригинал нетронутым. Храните обе величины: оригинал для отправки и отображения, и нормализованный ключ для совпадений.

Пример: если кто-то регистрируется как [email protected], храните [email protected] как контактный email. Постройте dedupe-ключ вроде [email protected] только если example.com есть в белом списке для удаления +tag. Иначе храните ключ ближе к оригиналу, например [email protected].

Если вы используете API валидации вроде Verimail, валидируйте сначала, затем нормализуйте. Такой порядок помогает не «исправить» битый адрес в вид, который выглядит валидным, но всё ещё не доставляется.

Как обрабатывать регистрацию, вход и слияние аккаунтов

Считайте введённый пользователем email меткой идентичности, а не тем, что можно свободно переписывать. При плюс-адресации две строки могут попадать в один ящик, но с точки зрения пользователя они не всегда одинаковы.

При регистрации принимайте +-теги и показывайте адрес точно так, как введён (включая часть с +). Это успокоит пользователя, что вы не «подправили» их email.

Для входа простое правило предотвращает сюрпризы: позволяйте вход с тем адресом, который пользователь использовал при создании аккаунта. Если кто-то вводит другое представление (например, без тега), и совпадение находится только по нормализованному ключу, не логиньте его молча. Попросите подтвердить право собственности, например обычным входом или проходом верификации по почте.

Слияние аккаунтов без ложных совпадений

Слияние должно требовать доказательств, а не только «нормализуются в одну строку». Безопасные варианты:

• Пользователь уже аутентифицирован в одном аккаунте и подтверждает другой.
• Оба аккаунта подтверждают владение через коды по почте.
• Слияние через поддержку с аудиторским журналом.

Пример: Алекс регистрируется как [email protected] для пробной рассылки. Через несколько месяцев коллега вводит [email protected] на общем устройстве. Автоматическое слияние только на основе нормализации может передать доступ чужому человеку.

Приглашения и реферальные ссылки

Решите заранее, считать ли +-теги уникальными идентичностями. Некоторые команды рассматривают каждый приглашённый адрес как отдельный для учёта, но при этом не разрешают создавать несколько аккаунтов без подтверждения владения приглашённым адресом.

Если вы валидируете email при регистрации, разделяйте границы: валидация помогает с доставкой и риском, а решения по идентичности (вход, слияние, приглашения) должны следовать явным продуктовым правилам.

Частые ошибки, которые блокируют реальных пользователей

Самый быстрый способ потерять хороших регистраций — считать валидный адрес «странным». Плюс-адресация — нормальная практика для людей, которые фильтруют почту, отслеживают утечки или держат регистрации разными.

Ловушка «слишком строгого regex’а»

Распространённая ошибка — regexp, разрешающий до @ только буквы, цифры, точки и дефисы. Это блокирует [email protected], хотя для многих провайдеров такой адрес валиден. Если ваши проверки писались давно, это часто причина.

Ещё ошибка — обрезать +tag и использовать обрезанную версию для доставки. Если пользователь ввёл [email protected], вы должны сохранять и отправлять на ту строку, которую он ввёл. Удаление тега может сломать правила входящих.

Чрезмерная нормализация и слияние разных людей

Обработка точек особенно рискована. Некоторые сервисы игнорируют точки в локальной части (sam.smith@... vs samsmith@...), но многие не делают этого. Предполагать одинаковое поведение везде — значит рисковать объединить разные ящики.

Более тонкая проблема — непоследовательность правил между системами. Если поток регистрации принимает [email protected], но ваш биллинг убирает тег, а маркетинг его сохраняет, один и тот же человек может появиться в базе несколько раз или быть объединён ошибочно.

Короткие «не делайте этого» проверки:

• Не отклоняйте + в локальной части.
• Не отправляйте почту на изменённую версию адреса, введённого пользователем.
• Не сворачивайте точки во всех доменах.
• Не применяйте разные правила в регистрации, биллинге и почтовых инструментах.

Нормализация — не верификация. Используйте нормализацию только для аккуратного дедупинга. Для отлова опечаток, неверных доменов и disposable-адресов пользуйтесь реальным валидатором (например, Verimail).

Мошенничество и злоупотребления: что означают и не означают +-теги

+tag обычно — знак внимательного пользователя, а не атакующего. Люди используют теги, чтобы фильтровать почту или видеть, кто слил их адрес.

Злоумышленники всё ещё могут злоупотреблять алиасами, чтобы создавать множество аккаунтов, потому что некоторые провайдеры считают [email protected] одним ящиком. Это может обойти правило «один аккаунт на email», если ваша система считает каждый +tag отдельной личностью.

Решение — не в запрете +tag. Это заблокирует реальных пользователей и не остановит злоумышленников, использующих другие стили алиасов (точки, алиасы домена, catch-all). Решите, что вы защищаете: создание аккаунтов, акции или идентичность.

Сосредоточьте трение на поведении, а не на формате. Например: ограничивайте скор регистрации, требуйте верификации для рискованных регистраций и отслеживайте множество регистраций, попадающих в один ящик за короткое время.

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

Обнаружение disposable-адресов важнее, чем запрет +-тегов. У одноразового почтового ящика другая цель — бросовые регистрации; +tag обычно указывает на нормальный почтовый ящик. Инструменты вроде Verimail помогают обнаруживать известные disposable-провайдеры, spam-trap и невалидные адреса, при этом продолжая принимать легитимные тегированные адреса.

Быстрые проверки перед выпуском

Большинство реальных проблем с плюс-адресацией — следствие ваших же действий: слишком строгий regex или правило дедупинга, тихо объединяющее аккаунты, которые должны оставаться разными.

Начните с принятия. Валидатор должен позволять + в локальной части (до @). Избегайте упрощений в regex, предполагающих только буквы, цифры, точки и подчёркивания. Если используете библиотеку, убедитесь, что она следует RFC, а не самодельным шаблонам.

Далее: разделяйте доставку и дедупинг. Всегда храните оригинальный email без изменений для отображения и отправки. Если вы создаёте нормализованный ключ для дедупа, держите его отдельно и документируйте правила, чтобы поддержка и инженерия принимали одни и те же решения.

Короткий чеклист перед релизом:

• Разрешайте + в локальной части.
• Храните оригинальный email без изменений; никогда не отправляйте почту на модифицированную версию.
• Используйте нормализованный ключ для дедупа только с прозрачными, зависящими от домена правилами.
• Подтверждайте сигналы домена до того, как флоу будет от них зависеть (существует ли домен, MX-записи, индикаторы disposable).
• Тестируйте с несколькими крупными провайдерами и хотя бы с одним контролируемым собственным доменом.

Для сигналов досягаемости почтового ящика валидируйте перед тем, как переводить пользователя на шаги вроде «подтвердите почту, чтобы продолжить». Валидатор поможет избежать блокировки реальных пользователей из-за опечаток или мёртвых доменов.

Наконец, прогоните простой набор тестов: [email protected], [email protected] и [email protected]. Убедитесь, что они могут зарегистрироваться, войти, сбросить пароль и получать сообщения без сюрпризов.

Пример: как избежать плохого дедупа в реальном потоке регистрации

Типичный случай: B2B‑приложение даёт бесплатные триалы. Один админ в Acme пробует продукт для разных клиентов и использует теги вроде [email protected], [email protected] и [email protected], чтобы хранить правила почты аккуратно. Это нормальное поведение плюс-адресации — письма всё ещё доставляются в один почтовый ящик.

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

Более безопасный подход — отделить «идентичность доставки» от «идентичности аккаунта». Сохраняйте оригинальный email целиком. Нормализованную форму используйте только как вспомогательное поле для совпадений, аналитики и ревью. Тогда:

• Разрешайте регистрацию [email protected], но требуйте подтверждение email перед активацией триала.
• Если нормализованный email совпадает с уже подтверждённым аккаунтом, показывайте понятное сообщение вроде «Возможно, у вас уже есть аккаунт. Хотите войти?»
• Если ваш продукт поддерживает несколько рабочих пространств, храните записи отдельно и объединяйте их позднее через явный поток слияния.

Для поддержки полезно показывать оба поля в профиле и логах: «Введённый email» и «Нормализовано для дедупа». Это облегчает объяснение ситуации и быстрое исправление.

Следующие шаги: валидируйте, измеряйте и держите базу в чистоте

Если вы принимаете +-теги, но обрабатываете их по‑разному в регистрации, входе и внутренних инструментах, вы будете постоянно получать дубликаты и путать пользователей. Быстрая починка — зафиксировать правила и применять их везде, где появляется поле email.

Простая политика подходит большинству команд: храните email точно так, как его ввёл пользователь, и используйте отдельное нормализованное значение только для совпадений и отчётности. Это позволяет дедупить без нарушения доставки и без сюрпризов для тех, кто полагается на теги.

Чеклист для релиза изменений:

• Задокументируйте правила нормализации (что вы меняете, а что никогда не трогаете) в одном общем месте.
• Примените одни и те же правила в регистрации, админ‑инструментах, импортах и рабочих процессах поддержки.
• Валидируйте при регистрации по RFC‑совместимой проверке синтаксиса, проверке домена, MX и обнаружению disposable.
• В сомнительных случаях разрешайте регистрацию, но требуйте подтверждения владения через почту.

Если вам нужна реализация, фокусирующаяся на достижимости и сигналах риска (без отклонения легитимных +tag), Verimail (verimail.co) предоставляет единый API валидации email, который сочетает проверку синтаксиса, домена и MX, а также обнаружение disposable и блоклистов.

После запуска изменений измеряйте результаты, чтобы ловить регрессии и настраивать правила. Отслеживайте: процент отклонённых регистраций и причины, процент подтверждений с bounce, уровень дубликатов по нормализованному ключу и обращения в поддержку о дублирующихся аккаунтах или неудачных регистрациях. Держите небольшой выбор отклонённых адресов (редактированных) и периодически их просматривайте. Если вы видите много реальных доменов в блок‑листах, ваша валидация или нормализация слишком агрессивны.