19 июн. 2025 г.·3 мин
Подводные камни нормализации email: точки, +теги и правила регистра
Ошибки нормализации email могут привести к случайным коллизиям аккаунтов. Узнайте, что безопасно нормализовать (а что нет) для точек, плюсовых тегов и регистра.
Почему нормализация email может сломать аккаунты пользователей
"Нормализовать 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], — это предположение.
Если вы считаете, что нужны трансформации, завязанные на провайдере, соберите сначала факты: посмотрите реальные случаи коллизий, применяйте правило строго к конкретным доменам и сохраняйте сырой адрес для поддержки и аудита.
Безопасный пошаговый подход
Добавьте проверки за несколько минут
Добавьте проверку синтаксиса RFC, проверки домена и MX-запросы одним вызовом.
Если вы нормализуете слишком агрессивно, вы сможете объединить двух реальных людей в один аккаунт. Более безопасный подход — разделять хранение, отображение, валидацию и идентификацию.
Практический поток:
- Сохраняйте сырой email точно так, как введён (для аудита и поддержки).
- Создайте очищенную версию для UI и сравнений (обрезка пробелов, удаление невидимых символов, понижение регистра домена).
- Проверяйте доставляемость отдельно (синтаксис, существование домена, MX-записи), не переписывая адрес в другую идентичность.
- Если вы строите ключ для дедупа (удаление точек/плюсов, правила провайдера), считайте совпадения "возможными" и требуйте доказательств перед связыванием аккаунтов.
- Постройте рабочий процесс на случай коллизии: если регистрация сопоставляется с существующим ключом, остановитесь и подтвердите владение, вместо автоматического присоединения.
Пример: кто-то регистрируется как [email protected], потом пытается как [email protected]. Для одного провайдера это может быть один и тот же ящик, для другого — разные. Рассматривайте это как сигнал к верификации, а не повод к слиянию.
Частые ошибки, приводящие к коллизиям
Большинство коллизий случаются, когда правило, верное для одного провайдера, применяют ко всем адресам.
Частые ошибки:
- Глобальное удаление точек и плюс-тегов.
- Понижение регистра всего адреса и использование его как уникального ключа аккаунта.
- Автоматическое объединение аккаунтов при совпадении нормализованной версии.
Когда две регистрации отображаются на одну каноническую строку, вы можете отвергать валидные регистрации, отправлять сбросы пароля не тому человеку и смешивать биллинг или права между пользователями.
Бычная чек-лист перед внедрением нормализации
Сократите плохие регистрации на раннем этапе
Отсеивайте недействительные адреса до того, как они создадут коллизии аккаунтов и тикеты в поддержку.
Перед выпуском любого правила нормализации ответьте на два вопроса: для чего вы оптимизируете (опрятность, меньше дубликатов или безопасность) и что произойдёт, если вы ошибётесь?
Базовая безопасная конфигурация:
- Сохраняйте сырой email и отдельное очищенное значение.
- Понижайте регистр только для домена.
- Избегайте удаления точек и плюсов, если это не строго ограничено и у вас нет плана на случай коллизий.
- Рассматривайте любое "нормализованное совпадение" как сигнал, а не как идентичность, пока пользователь не докажет контроль.
Следующие шаги: уменьшать дубликаты без догадок
Если дубликаты вам мешают, рассматривайте email как контактную информацию, а не как совершенный ключ идентичности. Храните оригинал для отправки и поддержки и ведите отдельное значение "нормализовано для поиска", которое можно менять позже без потери истории.
Чтобы сократить мусорные регистрации без рискованных правок, проверяйте адреса при регистрации и подтверждайте владение перед привязкой адреса к аккаунту. Если вам нужен API для этого слоя, Verimail (verimail.co) фокусируется на проверках валидности email: синтаксис, проверка домена и MX, обнаружение одноразовых адресов, не требуя от вас переписывать адреса так, чтобы это могло объединять пользователей.
Измеряйте последствия изменений: уровень отскоков (bounce), долю подтверждённых адресов и как часто похожие адреса оказываются разными людьми. Пусть метрики управляют следующими правилами, а не мифы о провайдерах.
Частые вопросы
Что на самом деле означает «нормализация email»?
Email normalization — это переписывание того, что ввёл пользователь, в более согласованную форму для хранения или сравнения, например обрезка пробелов или понижение регистра части адреса. Это становится рискованным, когда нормализация меняет идентичность — например при удалении точек или удалении +tag — потому что тогда два разных адреса могут выглядеть одинаково в вашей базе.
Какие шаги очистки обычно безопасны?
Обрезка начальных и конечных пробелов и удаление невидимых символов, появляющихся при копировании, обычно безопасны, потому что исправляют артефакты ввода, а не меняют идентичность. Понижение регистра только для части домена тоже обычно безопасно, так как домены в практике считаются нечувствительными к регистру.
Стоит ли приводить адреса к нижнему регистру при сохранении?
Понижение регистра только для части домена — хорошая отправная точка. Понижение регистра локальной части (до @) рискованно: стандарты допускают чувствительность к регистру, и в некоторых системах [email protected] и [email protected] могут быть разными почтовыми ящиками, хотя у многих провайдеров они работают одинаково.
Безопасно ли удалять точки в локальной части?
По умолчанию не удаляйте точки. Поведение Gmail, при котором точки игнорируются, не универсально: многие бизнес- или самохостинговые почтовые системы считают точки значимыми, поэтому [email protected] и [email protected] могут быть разными людьми.
Безопасно ли удалять «+теги» (плюсовая адресация)?
Нельзя делать это глобально. Многие провайдеры доставляют [email protected] в тот же ящик, что и [email protected], но другие рассматривают весь локальный фрагмент как уникальный, и организации могут по-разному маршрутизировать почту на основе тега.
Как избежать коллизий аккаунтов, если я применяю нормализацию?
Обращайтесь к нормализованным совпадениям как к подсказке, а не как к доказательству. Храните аккаунты раздельно, пока пользователь явно не докажет владение адресом (например, подтвердив его), и разработайте рабочий процесс для разрешения похожих адресов вместо молчаливого присоединения.
Стоит ли хранить исходный email или нормализованный?
Сохраняйте исходный адрес точно так, как его ввёл пользователь, для аудита, поддержки и отправки писем. Храните отдельное очищенное значение для поиска и сравнения, чтобы вы могли менять правила позже, не потеряв историю и не переписав то, что пользователь указал.
Могу ли я использовать «нормализованный email» как уникальный ключ аккаунта?
Используйте его лишь как удобный способ поиска аккаунта, а не как уникальный идентификатор. Если вы допускаете поиск без учёта регистра или упрощённое совпадение, убедитесь, что финальный шаг всё равно проверяет владение перед сбросом пароля или доступом к аккаунту.
Что насчёт алиасов, пересылки и субдоменов — можно ли их нормализовать?
Предположите, что они могут отличаться, если у вас нет твёрдых доменно-специфичных доказательств и безопасного плана действий. Считать [email protected] тем же, что и [email protected], или думать, что aliases всегда ведут в один ящик — это предположение, которое может объединить несвязанных пользователей.
Как сократить количество плохих регистраций без рискованной нормализации?
Проверяйте доставляемость отдельно от правил идентичности. Используйте проверки синтаксиса, проверки домена и MX-записи, а также обнаружение одноразовых ящиков, не переписывая адрес в иной строке; инструменты вроде Verimail фокусируются на этих шагах валидации, позволяя сохранить оригинальный адрес пользователя.