Интернационализированные адреса электронной почты: что ломается в продакшене

Почему корректно выглядящие адреса ломаются в продакшене

Адрес электронной почты может выглядеть нормально и при этом провалиться в тот момент, когда попадает в реальную систему. Главная причина в том, что то, что человек видит как один символ, может храниться разными байтами, по‑разному обрабатываться библиотеками или отклоняться старыми почтовыми серверами.

Типичный пример — søren@exämple.com. Это может быть валидный адрес, но он затрагивает сразу несколько уязвимых точек: Unicode в локальной части, интернационализированный домен и инфраструктуру почты, которая может поддерживать это или нет.

Сбоить может далеко от формы регистрации. Вы принимаете адрес, а затем не можете отправить письмо для сброса пароля, потому что ваш почтовый провайдер (или промежуточный реле) не поддерживает SMTPUTF8. Или ваш regex принимает адрес, а шаг «привести к нижнему регистру и обрезать» превращает его в нечто другое, не то, что ввёл пользователь.

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

Ложные допуски стоят по‑другому: некорректные адреса дают bounce‑ы, снижают доставляемость и портят списки. Некоторые правдоподобные вводы сознательно вредоносны: disposable‑домен, ролевые учётные записи для злоупотреблений или спам‑ловушки, которые вредят репутации отправителя.

Цель не в «принимать всё» или «блокировать всё». Цель — принимать реальных пользователей и при этом отсекать очевидно плохие вводы, используя проверки, соответствующие реальной работе почты: отделять представление от хранения, проверять достижимость домена (а не только наличие @) и избегать агрессивных трансформаций, которые тихо переписывают то, что ввёл пользователь.

Что такое интернационализированный адрес электронной почты

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

Наиболее распространённый случай — интернационализированный домен (IDN). Пользователь видит домен в своём письме, например maria@bücher.example или li@例子.公司. Под капотом многие системы конвертируют такой домен в ASCII‑форму (часто называемую punycode), чтобы DNS‑запросы и проверки MX работали надёжно.

Сложнее — Unicode в локальной части, например jó[email protected] или ユーザー@domain.com. Это попадает под Email Address Internationalization (EAI) и обычно доставляется через SMTPUTF8. Даже если адрес валиден по современным стандартам, некоторые серверы, старые библиотеки и внешние инструменты могут его отвергнуть. То есть вы можете принять адрес при регистрации, но провалиться при отправке.

Практическая картина поддержки сегодня:

• Unicode‑домены широко применимы, потому что их можно представить в ASCII для DNS.
• Unicode‑локальная часть менее последовательно поддерживается «от конца до конца» (форма регистрации, БД, CRM, почтовый провайдер и почтовый ящик все должны уметь с ним работать).
• Смешение скриптов и похожие символы повышают риск мошенничества.
• Отображение и хранение ломаются, когда софт предполагает «один символ = один байт».

Поэтому обычный yes/no‑regex недостаточен. Regex может отвергнуть легитимных пользователей (например, полностью блокируя не‑ASCII) или принять адреса, до которых вы не сможете доставить почту.

Лучше разделять проверку по сторонам. Для домена нормализуйте и конвертируйте в ASCII для DNS‑проверок. Для локальной части нужно принять политическое решение: вы полностью поддерживаете SMTPUTF8, разрешаете его с предупреждением или блокируете, потому что ваш стек почты не надёжен.

IDN и punycode: проблема домена

IDN (Internationalized Domain Name) — это домен с не‑ASCII символами, например с акцентами или нелатинскими скриптами. Пользователи видят Unicode‑форму, но DNS построен вокруг ASCII. Это несоответствие — источник многих багов в продакшене.

Чтобы смотреть MX‑записи, проверять домен или даже делать простую DNS‑проверку, обычно нужна ASCII‑форма домена. Конвертация делается по правилам IDNA и даёт punycode, который часто начинается с xn--. Так что пользователь вводит домен, который выглядит нормально, но в логах, базе или у внешнего провайдера вы можете увидеть версию xn--....

Punycode встречается в тех местах, где его стоит ожидать и обрабатывать:

• DNS и проверки MX
• Вызовы API для валидации или deliverability‑сервисов
• Логи и средства безопасности (чтобы аналитики могли безопасно копировать и вставлять)
• Хранилище и дедупликация (чтобы один и тот же домен не хранился в двух формах)

Две распространённые ошибки:

• Валидировать только Unicode‑строку домена и никогда не конвертировать её перед DNS‑проверкой.
• Отвергать любой домен с не‑ASCII символами, блокируя легитимных пользователей.

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

Практический подход: принимайте то, что ввёл пользователь, а затем нормализуйте внутри:

• Принимайте Unicode‑домен в поле ввода.
• Конвертируйте домен в ASCII (punycode) для DNS и MX‑проверок.
• Храните обе формы, когда можно: Unicode для отображения, ASCII — для технических проверок и сопоставления.
• Отмечайте подозрительные паттерны (смешение скриптов, confusables) для дополнительной проверки или step‑up верификации.

Нормализация Unicode: почему один и тот же текст не всегда одинаков

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

Простой пример — буква «é». Она может быть одним кодовым пунктом (U+00E9) или двумя: «e» (U+0065) плюс комбинирующий акцент (U+0301). Для человека они выглядят одинаково, но база данных может трактовать их как разные.

NFC vs NFKC (и почему это важно)

Нормализация приводит текст к согласованной форме.

• NFC (Normalization Form C) композитует символы там, где возможно. Обычно сохраняет то, что имел в виду пользователь, и делает проверки равенства надёжнее.
• NFKC идёт дальше и преобразует совместимые символы в более простые эквиваленты (например, некоторые полноширинные формы). Это может улучшать консистентность, но также менять смысл и плохо взаимодействовать со спуфингом и confusables, если применять бездумно.

Для обработки email NFC часто является наиболее безопасным выбором для операций «сделать равно».

Обработка регистра: что понижать в регистр (а что нет)

Правила регистра отличаются между сторонами адреса:

• Домен (справа от @): безопасно считать нечувствительным к регистру. Приведение к нижнему регистру — стандарт.
• Локальная часть (слева от @): технически чувствительна к регистру, хотя многие провайдеры его игнорируют. Приведение к нижнему может слить два разных адреса на некоторых системах.

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

Когда нормализовать (и когда сохранять оригинал)

Нормализуйте в тех моментах, где важна согласованность:

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

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

Где системы в продакшене обычно дают сбой

Большинство багов с интернационализированными адресами появляются на стыках, где одна система делает одно предположение, а следующая — другое. Адрес выглядит нормально для пользователя, но что‑то в цепочке меняет его, отвергает или считает два визуально одинаковых значения разными.

Типичный провал начинается на форме регистрации. Фронтенд‑правила часто допускают только A‑Z, 0‑9 и несколько символов. Мобильные клавиатуры вставляют «умные» знаки препинания, автозаполнение добавляет невидимый пробел в конце. Авто‑понижение регистра тоже может вести себя странно вне базовой ASCII‑области.

На бэкенде маленькие шаги по очистке могут быть разрушительными. Триминг полезен, но удаление «непечатаемых» символов может удалить валидные Unicode‑метки. Ограничения длины — ещё одна тихая проблема: интернационализированные домены при конвертации в punycode «выростают», и вы можете неожиданно упереться в лимит.

Базы данных добавляют свои ловушки. Сопоставления и правила сравнения решают, равны ли две строки. Если одна система хранит композитную форму, а другая позже присылает разложенную, проверки уникальности могут не сработать. Это создаёт дубликаты аккаунтов или блокирует пользователя из‑за несоответствия "уже существует".

Проблемы чаще всего проявляются в:

• Валидации на клиенте и виджетах ввода
• Санации на сервере: обрезания и ограничения по длине
• Колляции базы данных и уникальных индексов
• Интеграциях (CRM, аналитика, служба поддержки, процессоры логов)
• Исходящей почте, если она не поддерживает SMTPUTF8

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

Реалистичная цепочка отказа выглядит так: пользователь регистрируется с Unicode‑доменом, вы сохраняете его, ваш CRM нормализует иначе, а провайдер почты отказывает при SMTPUTF8. В итоге у вас один пользователь, две несовпадающие строки и письмо, которое не дошло.

Пошагово: более безопасный рабочий процесс валидации

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

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

2. Сделайте реальную синтаксическую проверку. Оценивайте как «структурно возможен ли этот адрес», а не как «обязательно ли почта дойдёт». Современные правила шире большинства regex, особенно для международных символов.

3. Примите решение по нормализации и уникальности. Храните сырой адрес плюс каноническую форму (часто NFC) для проверок равенства. Если email — уникальный ключ в системе, зафиксируйте правило, считать ли визуально одинаковые, но по‑разному закодированные вводы за один аккаунт.

4. Обрабатывайте домен правильно. Нормализуйте и конвертируйте домен в ASCII (punycode) перед любой работой с DNS. Затем проверяйте домен и смотрите MX‑записи (и, при политике, fallback на A/AAAA).

5. Сформируйте политику для Unicode‑локальной части. Если ваш провайдер исходящей почты не гарантирует доставку по SMTPUTF8, принимайте регистрацию только при наличии плана‑запасного варианта (верификация внутри приложения, альтернативный контакт или явное предупреждение о возможных ограничениях).

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

Валидация vs доставляемость: что вы можете доказать

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

Валидация всё ещё даёт сильные сигналы до сохранения адреса или отправки:

• Синтаксис допустим (включая правила SMTPUTF8 при необходимости)
• Домен существует и резолвится
• Есть MX‑записи (или домен настроен принимать почту)
• Адрес или домен выглядят рискованно (например, disposable)

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

Более безопасный подход — двухэтапный:

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

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

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

Самый быстрый способ потерять реальных регистраций — считать всё, что вне ASCII, невалидным. Многие легитимные провайдеры поддерживают интернационализированные домены, и часть пользователей действительно ими пользуется.

Ошибка 1: слишком строгие правила «только ASCII»

Много кода в продакшене всё ещё предполагает, что email — это A‑Z, 0‑9, точки и несколько символов. Это ломает IDN‑домены и гарантирует ложные отказы в глобальных продуктах.

Ошибка 2: понижение регистра или нормализация всей строки

Понижение регистра домена допустимо. Понижение регистра локальной части — рискованно.

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

«Полезные» трансформации, которые подводят:

• Чрезмерный триминг (или удаление символов, которые вы считаете невидимыми)
• Понижение регистра всего адреса
• Применение одной формы нормализации повсеместно без тестов экспорта и интеграций
• Авто‑удаление точек или плюс‑тегов (поведение, специфичное для отдельных провайдеров)

Ошибка 3: показывать punycode пользователям

Бэкенду может потребоваться punycode для проверок DNS, но в UI обычно стоит показывать домен в форме пользователя. Показ xn--... в подтверждениях или ошибках выглядит подозрительно и пугающе, даже если адрес корректен.

Ошибка 4: считать, что Unicode в локальной части всегда работает

Даже если адрес валиден по спецификации, не все почтовые серверы поддерживают SMTPUTF8. Если вы принимаете Unicode‑локальную часть, будьте готовы к различиям в доставляемости у разных провайдеров.

Ошибка 5: игнорирование артефактов при вставке

Копирование и вставка вносят неразрывные пробелы, символы с нулевой шириной и лишние пробелы вокруг @. Пользователь не видит эти проблемы, а ваша валидация — видит.

Пример: пользователь вставляет name@пример.рф с завершающим пробелом. Если вы валидируете до триминга, вы отклоните адрес. Если вы пере‑саначите, вы можете изменить локальную часть.

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

Интернационализированные адреса могут работать end‑to‑end, но только если каждый слой согласен, что он принимает, хранит и отправляет. Перед релизом прогоните проверки, имитирующие поведение продакшена, а не только unit‑тесты.

Практический чек‑лист перед запуском

• Подтвердите, что форма регистрации допускает Unicode там, где вы это планируете (домен, локальная часть или обе). Если вы не поддерживаете Unicode в локальной части, укажите это прямо при вводе.
• Выберите правило нормализации (обычно NFC) и применяйте его последовательно в браузере, API, фоновых задачах и админ‑инструментах.
• Конвертируйте домен в ASCII (punycode) перед работой с DNS и храните сопоставимые формы, чтобы проверки не расходились.
• Сделайте правила уникальности аккаунта согласованными с логикой входа и поиска. Решите, должны ли визуально одинаковые, но по‑разному закодированные адреса соответствовать одному пользователю.
• Протестируйте исходящую почту по вашему реальному маршруту (провайдер, реле, библиотека) на примерах с IDN‑доменом и Unicode‑локальной частью.

Проверки, которые забывают до первых тикетов

Убедитесь, что логи и админ‑инструменты корректно отображают удобочитаемую версию без mojibake и что экспорт/импорт не ломает данные. Также проверьте все системы, которые касаются адреса: события аналитики, синхронизация с CRM, вебхуки, CSV‑экспорт и загрузка в хранилище данных. Многие ошибки проявляются при экспорте, а не при вводе.

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

Пример сценария и следующие шаги

Пользователь регистрируется как marta@bücher.example. На первый взгляд всё нормально, потому что домен в Unicode. Ваша система должна трактовать домен как IDN.

С точки зрения домена: храните удобную для пользователя форму, но для валидации используйте DNS‑безопасную форму. Конвертируйте bücher.example в punycode (xn--bcher-kva.example) перед MX‑запросами. Если вы проверяете только Unicode‑форму, некоторые DNS‑библиотеки могут падать или вести себя непоследовательно.

Теперь тонкая часть: один и тот же email можно ввести несколькими способами, которые визуально идентичны. Допустим, пользователь вводит márta@bücher.example, но «á» может быть одним символом или «a» плюс комбинирующий акцент. Если вы храните только сырой ввод, у пользователя могут появиться две учётные записи, которые выглядят одинаково в UI.

Нормализация решает это. Нормализуйте в NFC перед сравнением, хранением, rate‑limiting и дедупом, и применяйте те же правила везде, где затрагивается адрес.

Локальная часть (до @) — место, где нужна чёткая политика. SMTPUTF8 разрешает Unicode в локальной части, но не все провайдеры поддерживают это полноценно. Практичная политика для многих продуктов:

• По умолчанию принимайте ASCII‑локальные части.
• Если локальная часть содержит Unicode, принимайте, но требуйте подтверждения или показывайте явное предупреждение.
• Если ваш продукт сильно зависит от доставки почты (сброс пароля, счета), блокируйте Unicode‑локальные части, если вы не протестировали поддержку SMTPUTF8 по всей цепочке почты.

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

Дальнейшие шаги, которые защищают вас и при этом не отсекают реальных пользователей:

• Зафиксируйте политику по Unicode‑локальной части (принимать, предупреждать или блокировать) и применяйте её последовательно в вебе, мобильных и админ‑инструментах.
• Нормализуйте в NFC перед хранением, сравнением и дедупом.
• Протестируйте пограничные случаи: IDN‑домены, смешение скриптов, композитные и разложенные символы, ввод через вставку.
• Мониторьте показатели: успешность подтверждений, количество bounce‑ов и ошибки «email уже используется» после нормализации.
• Храните достаточно логов решений валидации, чтобы быстро разбираться с ложными отказами.