Обрабатывайте плюс‑адресацию при регистрациях, не блокируя реальных пользователей. Узнайте безопасную нормализацию для дедупинга, правила хранения и проверки валидации.
Да, многие реальные пользователи полагаются на плюс-адресацию вроде [email protected], и многие почтовые провайдеры доставляют такие письма в ту же папку, что и [email protected]. Рассматривайте это как обычный формат, а не как подозрительный признак.
Люди используют теги, чтобы фильтровать письма в папки, отслеживать, где использовался адрес, и разделять разные регистрации. Блокировка + часто отбрасывает внимательных, законных клиентов.
Самый безопасный вариант — сохранять и отображать электронную почту точно так, как ввёл пользователь, и отправлять письма именно на эту строку. Изменение адреса может нарушить правила входящих, запутать пользователей и создать проблемы для поддержки.
Не выполняйте дедупликацию, удаляя +tag в основном поле email. Если нужно объединять записи, создайте отдельный внутренний «ключ сравнения» и оставляйте оригинальный адрес нетронутым для доставки и отображения.
Требуйте в качестве основного идентификатора тот же адрес, который был использован при регистрации. Если кто-то вводит вариант, который совпадает только по нормализованному ключу, попросите подтвердить владение (например, через верификацию по электронной почте), а не выполняйте тихую авторизацию.
Нормализуйте аккуратно: убирайте внешние пробелы, отклоняйте управляющие символы и приводите домен к нижнему регистру. Удалять +tag можно только для доменов из явного белого списка, поведение которых вы понимаете, и только в отдельном ключе для дедупинга.
Слишком строгий паттерн — частая причина. Шаблон, который разрешает только буквы, цифры и точки до @, будет отбрасывать валидные адреса с +. Используйте валидацию, соответствующую RFC, вместо самописных ограничений.
Нет, поддержка зависит от конфигурации принимающего домена, а не только от бренда провайдера. Считайте её возможной, проверяйте сигналы доставки и избегайте жёстких правил вроде «+ всегда работает» или «+ никогда не работает».
Тег + обычно указывает на обычную почтовую ящик, но злоумышленники могут использовать псевдонимы, чтобы создавать много «уникально выглядящих» адресов для одного входящего. Решайте такие случаи продуктовыми правилами — верификация, лимиты по частоте, скоринг риска — а не запретом +.
Проверяйте досягаемость и риск: синтаксис, проверки домена, MX-записи и обнаружение disposable-провайдеров, при этом продолжайте принимать адреса с тегами. Сохраняйте результаты валидации (статус, причина, отметка времени) отдельно от строки с email, чтобы не переписывать то, что ввёл пользователь.
+-теги создают проблемы при регистрацияхМногие реальные люди используют адреса вроде [email protected]. Часть +tag — это тег (его ещё называют subaddress). Многие провайдеры доставляют такие письма в тот же почтовый ящик, что и [email protected], но тег позволяет пометить, где именно был использован адрес.
Люди применяют теги по практическим причинам: фильтрация (правила, которые отправляют сообщения в папки), отслеживание (понять, кто слил или продал адрес), и разделение регистраций (чтобы каждый аккаунт выглядел как отдельный адрес). Особенно часто это встречается у пользователей Gmail и Fastmail.
Проблемы начинаются, когда форма регистрации считает + недопустимым или подозрительным. Это блокирует внимательных, законных клиентов. Ещё одна распространённая ошибка — обрезать тег и сохранять только базовый адрес. Это может свести несколько регистраций к одному аккаунту и вызвать запутанность при входе и восстановлении пароля позже.
Типичные ошибки:
+, хотя на них приходят письма.name+billing@... и name+personal@... в одного пользователя.Считайте плюс-адресацию вариантом форматирования, а не доказательством мошенничества. Принимайте адреса, на которые можно доставить почту, и выполняйте дедупинг только когда это действительно безопасно. Самое простое правило, которое предотвращает большинство проблем: сохраняйте оригинальный адрес точно так, как его ввёл пользователь, и (если нужен ключ для сравнения) создавайте отдельный ключ только для поиска/сравнения.
Если вы запускаете валидацию email (например, через сервис Verimail), проверка должна концентрироваться на досягаемости и сигналах риска, а не на наказании пользователей, которые полагаются на +-теги.
Плюс-адресация — это способ добавить тег к email без создания нового почтового ящика. Обычный шаблон — [email protected], где часть после + помогает пользователю пометить, где был использован адрес.
Email состоит из двух основных частей: локальной части и домена. В [email protected] name+tag — локальная часть, а example.com — домен.
Три понятия часто путают:
+.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 protected]».
В то же время многие продукты хотят иметь второй ключ, который помогает находить дубликаты и поддерживать порядок. Именно сюда и идёт нормализация: в отдельное внутреннее поле, не в адрес для отправки.
Практическая модель данных содержит два поля с разными задачами:
Информацию о верификации храните отдельно. Валидация — это свойство адреса в конкретный момент времени. Храните статус (valid, risky, invalid), причину (например, отсутствует MX) и отметку времени.
Нормализация должна быть консервативной. Приведение домена к нижнему регистру обычно безопасно. Приведение локальной части к нижнему регистру в большинстве случаев безопасно на практике, но будьте последовательны и избегайте сюрпризов. Главное — не удалять +tag, если это делается не только для внутреннего ключа и вы не уверены, что это не сольёт разных людей.
Конкретный пример: сохраняйте [email protected] как оригинал, но держите ключ вроде [email protected] для совпадения. Письма по-прежнему попадут туда, куда ожидает пользователь, а ваша система увидит возможные дубликаты без переписывания адреса доставки.
Принимайте реальные адреса (включая плюс-адресацию), одновременно замечая дубликаты через отдельный ключ, а не переписывая то, что ввёл пользователь.
Практический подход:
Обрежьте и очистите ввод. Удалите начальные и конечные пробелы. Отклоняйте управляющие символы (табуляции, переводы строк, нули), которые могут скрыть другой адрес или сломать логи и рассылки.
Запустите базовую проверку синтаксиса, но не запрещайте +. Валидная локальная часть может содержать + и другие символы. Сосредоточьтесь на явных ошибках: отсутствует @, пустые части или запрещённые пробелы.
Нормализуйте домен аккуратно. Приводите домен к нижнему регистру и нормализуйте последовательно. Если вы поддерживаете интернационализированные домены, конвертируйте их стандартным способом, чтобы exämple.com и его ASCII‑форма соответствовали одному домену.
Правила для локальной части применяйте только когда контролируете риск. Не удаляйте +tag глобально. Если вы хотите дедупить [email protected] с [email protected], делайте это только для доменов в явном белом списке, поведение которых вы проверили.
Создайте стабильный dedupe-ключ, оставив оригинал нетронутым. Храните обе величины: оригинал для отправки и отображения, и нормализованный ключ для совпадений.
Пример: если кто-то регистрируется как [email protected], храните [email protected] как контактный email. Постройте dedupe-ключ вроде [email protected] только если example.com есть в белом списке для удаления +tag. Иначе храните ключ ближе к оригиналу, например [email protected].
Если вы используете API валидации вроде Verimail, валидируйте сначала, затем нормализуйте. Такой порядок помогает не «исправить» битый адрес в вид, который выглядит валидным, но всё ещё не доставляется.
Считайте введённый пользователем email меткой идентичности, а не тем, что можно свободно переписывать. При плюс-адресации две строки могут попадать в один ящик, но с точки зрения пользователя они не всегда одинаковы.
При регистрации принимайте +-теги и показывайте адрес точно так, как введён (включая часть с +). Это успокоит пользователя, что вы не «подправили» их email.
Для входа простое правило предотвращает сюрпризы: позволяйте вход с тем адресом, который пользователь использовал при создании аккаунта. Если кто-то вводит другое представление (например, без тега), и совпадение находится только по нормализованному ключу, не логиньте его молча. Попросите подтвердить право собственности, например обычным входом или проходом верификации по почте.
Слияние должно требовать доказательств, а не только «нормализуются в одну строку». Безопасные варианты:
Пример: Алекс регистрируется как [email protected] для пробной рассылки. Через несколько месяцев коллега вводит [email protected] на общем устройстве. Автоматическое слияние только на основе нормализации может передать доступ чужому человеку.
Решите заранее, считать ли +-теги уникальными идентичностями. Некоторые команды рассматривают каждый приглашённый адрес как отдельный для учёта, но при этом не разрешают создавать несколько аккаунтов без подтверждения владения приглашённым адресом.
Если вы валидируете email при регистрации, разделяйте границы: валидация помогает с доставкой и риском, а решения по идентичности (вход, слияние, приглашения) должны следовать явным продуктовым правилам.
Самый быстрый способ потерять хороших регистраций — считать валидный адрес «странным». Плюс-адресация — нормальная практика для людей, которые фильтруют почту, отслеживают утечки или держат регистрации разными.
Распространённая ошибка — 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 protected], [email protected] и [email protected]. Убедитесь, что они могут зарегистрироваться, войти, сбросить пароль и получать сообщения без сюрпризов.
Типичный случай: B2B‑приложение даёт бесплатные триалы. Один админ в Acme пробует продукт для разных клиентов и использует теги вроде [email protected], [email protected] и [email protected], чтобы хранить правила почты аккуратно. Это нормальное поведение плюс-адресации — письма всё ещё доставляются в один почтовый ящик.
Проблемы начинаются, когда дедуп слишком агрессивен. Если вы обрезаете всё после + и считаете все эти регистрации одним пользователем, вы можете заблокировать создание второго триала. Сброс пароля уйдёт в первый аккаунт, а не в тот, который хочет админ.
Более безопасный подход — отделить «идентичность доставки» от «идентичности аккаунта». Сохраняйте оригинальный email целиком. Нормализованную форму используйте только как вспомогательное поле для совпадений, аналитики и ревью. Тогда:
[email protected], но требуйте подтверждение email перед активацией триала.Для поддержки полезно показывать оба поля в профиле и логах: «Введённый email» и «Нормализовано для дедупа». Это облегчает объяснение ситуации и быстрое исправление.
Если вы принимаете +-теги, но обрабатываете их по‑разному в регистрации, входе и внутренних инструментах, вы будете постоянно получать дубликаты и путать пользователей. Быстрая починка — зафиксировать правила и применять их везде, где появляется поле email.
Простая политика подходит большинству команд: храните email точно так, как его ввёл пользователь, и используйте отдельное нормализованное значение только для совпадений и отчётности. Это позволяет дедупить без нарушения доставки и без сюрпризов для тех, кто полагается на теги.
Чеклист для релиза изменений:
Если вам нужна реализация, фокусирующаяся на достижимости и сигналах риска (без отклонения легитимных +tag), Verimail (verimail.co) предоставляет единый API валидации email, который сочетает проверку синтаксиса, домена и MX, а также обнаружение disposable и блоклистов.
После запуска изменений измеряйте результаты, чтобы ловить регрессии и настраивать правила. Отслеживайте: процент отклонённых регистраций и причины, процент подтверждений с bounce, уровень дубликатов по нормализованному ключу и обращения в поддержку о дублирующихся аккаунтах или неудачных регистрациях. Держите небольшой выбор отклонённых адресов (редактированных) и периодически их просматривайте. Если вы видите много реальных доменов в блок‑листах, ваша валидация или нормализация слишком агрессивны.