Ошибки нормализации email могут привести к случайным коллизиям аккаунтов. Узнайте, что безопасно нормализовать (а что нет) для точек, плюсовых тегов и регистра.
Email normalization — это переписывание того, что ввёл пользователь, в более согласованную форму для хранения или сравнения, например обрезка пробелов или понижение регистра части адреса. Это становится рискованным, когда нормализация меняет идентичность — например при удалении точек или удалении +tag — потому что тогда два разных адреса могут выглядеть одинаково в вашей базе.
Обрезка начальных и конечных пробелов и удаление невидимых символов, появляющихся при копировании, обычно безопасны, потому что исправляют артефакты ввода, а не меняют идентичность. Понижение регистра только для части домена тоже обычно безопасно, так как домены в практике считаются нечувствительными к регистру.
Понижение регистра только для части домена — хорошая отправная точка. Понижение регистра локальной части (до @) рискованно: стандарты допускают чувствительность к регистру, и в некоторых системах [email protected] и [email protected] могут быть разными почтовыми ящиками, хотя у многих провайдеров они работают одинаково.
По умолчанию не удаляйте точки. Поведение Gmail, при котором точки игнорируются, не универсально: многие бизнес- или самохостинговые почтовые системы считают точки значимыми, поэтому [email protected] и [email protected] могут быть разными людьми.
Нельзя делать это глобально. Многие провайдеры доставляют [email protected] в тот же ящик, что и [email protected], но другие рассматривают весь локальный фрагмент как уникальный, и организации могут по-разному маршрутизировать почту на основе тега.
Обращайтесь к нормализованным совпадениям как к подсказке, а не как к доказательству. Храните аккаунты раздельно, пока пользователь явно не докажет владение адресом (например, подтвердив его), и разработайте рабочий процесс для разрешения похожих адресов вместо молчаливого присоединения.
Сохраняйте исходный адрес точно так, как его ввёл пользователь, для аудита, поддержки и отправки писем. Храните отдельное очищенное значение для поиска и сравнения, чтобы вы могли менять правила позже, не потеряв историю и не переписав то, что пользователь указал.
Используйте его лишь как удобный способ поиска аккаунта, а не как уникальный идентификатор. Если вы допускаете поиск без учёта регистра или упрощённое совпадение, убедитесь, что финальный шаг всё равно проверяет владение перед сбросом пароля или доступом к аккаунту.
Предположите, что они могут отличаться, если у вас нет твёрдых доменно-специфичных доказательств и безопасного плана действий. Считать [email protected] тем же, что и [email protected], или думать, что aliases всегда ведут в один ящик — это предположение, которое может объединить несвязанных пользователей.
Проверяйте доставляемость отдельно от правил идентичности. Используйте проверки синтаксиса, проверки домена и MX-записи, а также обнаружение одноразовых ящиков, не переписывая адрес в иной строке; инструменты вроде Verimail фокусируются на этих шагах валидации, позволяя сохранить оригинальный адрес пользователя.
"Нормализовать email" значит взять то, что ввёл пользователь, и переписать в более согласованную форму перед сохранением или сравнением. Это может быть простой обрезкой пробелов или агрессивной правкой — удалением точек, удалением плюсовых тегов или применением правил, специфичных для провайдера.
Риск прост: небольшая правка может сделать два разных адреса одинаковыми в хранилище. Когда это происходит, ваша система может случайно объединить личности. Сбросы паролей могут уйти в чужой почтовый ящик, один пользователь может оказаться в аккаунте другого, и журнал аудита перестаёт вызывать доверие.
Пример обычной коллизии: Пользователь A регистрируется как [email protected], а Пользователь B — как [email protected]. Если ваша система удаляет точки в локальной части (до @), оба станут одной и той же строкой, хотя многие почтовые системы рассматривают их как разные почтовые ящики.
Эти коллизии тяжело заметить, потому что они редко проявляют себя шумно:
Цель не в том, чтобы угадывать "настоящий" адрес. Цель — избегать явного мусора и опечаток, не меняя идентичность. Более безопасный подход — сохранять оригинал, применять только консервативную очистку для сравнений и отдельно проверять доставляемость.
Нормализация направлена на то, чтобы адреса были достаточно согласованными для хранения и сопоставления. Ловушка — путать «согласованность» со «тоже самой персоной».
Часто смешиваются две задачи:
Адрес электронной почты состоит из двух частей: локальной (до @) и доменной (после @). Большинство сюрпризов связано с локальной частью, потому что провайдеры и корпоративные почтовые серверы могут интерпретировать её по-разному.
Команды часто пробуют обрезать пробелы, приводить в нижний регистр, удалять точки и убирать +tag. Ключевая проблема в том, что универсальной "безопасной канонической формы" для всех провайдеров не существует. Некоторые игнорируют точки, некоторые — нет. Некоторые поддерживают плюсовую адресацию, другие рассматривают + как обычный символ. Даже чувствительность к регистру стандартизирована одним образом, а в практике обрабатывается иначе.
Более безопасный рецепт: храните сырой ввод, создавайте отдельный ключ для сравнений с теми трансформациями, которые вы можете обосновать, и никогда не позволяйте этому ключу молча объединять аккаунты.
Некоторые шаги очистки решают реальные проблемы ввода, не меняя смысл адреса.
Самые безопасные приёмы:
Важно сохранять обе версии. Используйте очищенную версию для поиска и валидации, но храните точную строку, введённую пользователем, чтобы поддержка могла ответить: "Что ввёл пользователь?" и "Что мы изменили?".
Распространённый миф — точки в адресах никогда не имеют значения. Это мнение в основном исходит из Gmail.
Gmail считает точки в локальной части незначащими, поэтому [email protected] и [email protected] попадут в один и тот же ящик. Некоторые настройки Google Workspace ведут себя похоже, но это нельзя безопасно предполагать для всех доменов.
За пределами Gmail точки могут быть принципиальными. Многие почтовые системы трактуют локальную часть как точный текст, поэтому [email protected] и [email protected] могут быть разными людьми.
Рекомендация: не удаляйте точки, если вы не уверены, что домен следует правилу Gmail, и вы готовы принять риск для идентичности. Если вы пытаетесь уменьшить дубликаты, воспринимайте совпадения без точек как "возможное совпадение", требующее подтверждения от пользователя.
Плюсовые теги выглядят как [email protected]. Люди используют их для трекинга регистраций, маршрутизации квитанций и фильтрации почты.
Ловушка — считать, что alex+news@... всегда то же самое, что alex@.... Некоторые провайдеры игнорируют тег и доставляют на базовый ящик. Другие считают полный адрес отличным, или организации могут по-разному маршрутизировать почту в зависимости от тега.
Если вы удаляете +tag при очистке, вы можете создать коллизии, которых пользователь не ожидал. Например, кто-то может намеренно создать отдельные аккаунты [email protected] и [email protected]. Если вы сохраните оба как [email protected], вы можете объединить профили и отправить сброс пароля не тому человеку.
Более безопасное правило:
+..., если у вас нет узкой, протестированной причины для конкретного домена.Стандарты допускают чувствительность локальной части к регистру, то есть [email protected] и [email protected] теоретически могут быть разными ящиками.
На практике многие крупные провайдеры считают локальную часть нечувствительной к регистру, поэтому смешанный регистр обычно работает. Но полагаться на это повсеместно нельзя.
Консервативный подход:
Многие ошибки нормализации начинаются с «Этот провайдер ведёт себя как Gmail». Такое предположение быстро ломается.
Даже внутри экосистемы Google поведение не всегда такое простое, как ожидают. А уходя за пределы gmail.com, правила могут полностью измениться.
Алиасы, пересылки и субдомены добавляют ещё больше путаницы. Кто-то может зарегистрироваться с алиасом, который пересылает в их ящик. Другой человек может реально владеть похожим адресом, который вы сочли эквивалентным. Считать [email protected] тем же, что и [email protected], — это предположение.
Если вы считаете, что нужны трансформации, завязанные на провайдере, соберите сначала факты: посмотрите реальные случаи коллизий, применяйте правило строго к конкретным доменам и сохраняйте сырой адрес для поддержки и аудита.
Если вы нормализуете слишком агрессивно, вы сможете объединить двух реальных людей в один аккаунт. Более безопасный подход — разделять хранение, отображение, валидацию и идентификацию.
Практический поток:
Пример: кто-то регистрируется как [email protected], потом пытается как [email protected]. Для одного провайдера это может быть один и тот же ящик, для другого — разные. Рассматривайте это как сигнал к верификации, а не повод к слиянию.
Большинство коллизий случаются, когда правило, верное для одного провайдера, применяют ко всем адресам.
Частые ошибки:
Когда две регистрации отображаются на одну каноническую строку, вы можете отвергать валидные регистрации, отправлять сбросы пароля не тому человеку и смешивать биллинг или права между пользователями.
Перед выпуском любого правила нормализации ответьте на два вопроса: для чего вы оптимизируете (опрятность, меньше дубликатов или безопасность) и что произойдёт, если вы ошибётесь?
Базовая безопасная конфигурация:
Если дубликаты вам мешают, рассматривайте email как контактную информацию, а не как совершенный ключ идентичности. Храните оригинал для отправки и поддержки и ведите отдельное значение "нормализовано для поиска", которое можно менять позже без потери истории.
Чтобы сократить мусорные регистрации без рискованных правок, проверяйте адреса при регистрации и подтверждайте владение перед привязкой адреса к аккаунту. Если вам нужен API для этого слоя, Verimail (verimail.co) фокусируется на проверках валидности email: синтаксис, проверка домена и MX, обнаружение одноразовых адресов, не требуя от вас переписывать адреса так, чтобы это могло объединять пользователей.
Измеряйте последствия изменений: уровень отскоков (bounce), долю подтверждённых адресов и как часто похожие адреса оказываются разными людьми. Пусть метрики управляют следующими правилами, а не мифы о провайдерах.