Контрольный список валидации синтаксиса email, соответствующий RFC, для регистраций

Почему валидация синтаксиса email порождает так много багов

Адреса электронной почты кажутся простыми, пока вы не начнёте их валидировать. Многие баги в продакшне возникают из-за отношения к email как к «нескольким буквам, @ и точке» с опорой на быстрый регекс. Реальные адреса допускают больше вариаций, чем ожидают формы, и небольшие решения в парсинге могут превратить валидный адрес в «недействительный».

Частая путаница — в смешении двух разных вопросов:

• Что допускают стандарты (правила синтаксиса)
• Что ваш продукт хочет принимать (ваша политика)

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

Отклонение валидных адресов ломает реальные вещи. Кто-то вводит полностью корректный адрес с плюс-адресацией или субдоменом, форма говорит «недопустимо», и пользователь уходит. Вы теряете регистрацию и часто не собираете достаточно данных, чтобы разобраться, почему.

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

Большинство сбоев в продакшне сводятся к нескольким шаблонам: регексы слишком строгие (или слишком свободные), неправильное разделение вокруг @, чрезмерная обрезка или «нормализация», и смешивание синтаксических проверок с проверками доставляемости.

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

В этой статье мы сосредоточимся на синтаксисе: записан ли адрес в корректном формате. Это не доказывает, что почтовый ящик существует или что домен может принимать почту — такие проверки относятся к последующим слоям.

Что означает «соответствующий RFC» (и чего это не значит)

«Соответствующий RFC» в основном про синтаксис: можно ли распарсить строку как адрес по правилам RFC 5322? Это полезно, но лишь первый фильтр. Синтаксически валидный адрес всё ещё может быть недоставляемым, небезопасным или низкого качества.

Синтаксис vs проверка домена vs существование почтового ящика

Думайте о валидации слоями:

• Синтаксис: правильно ли форматирован адрес (символы, разделители, правила экранирования)?
• Домен: может ли домен принимать почту (DNS, MX-записи)?
• Существование почтового ящика: существует ли конкретный почтовый ящик? Это самый сложный уровень, потому что многие серверы не подтверждают его.

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

Что на практике значит "RFC-compliant"

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

Некоторые команды сознательно ужесточают правила. Это допустимо, но должно быть осознанным решением, задокументированным и покрытым тестами. Например, вы можете всё ещё отклонять:

• Отсутствие @ или отсутствие локальной части или домена
• Управляющие символы, невидимые пробелы или вставленные переводы строки
• Метки домена, начинающиеся или заканчивающиеся дефисом
• Юникод, который вы не поддерживаете насквозь
• Чрезмерно длинные вводы (задайте максимум длины, чтобы предотвратить злоупотребления)

Сценарий: [email protected] синтаксически может быть валиден. Если у домена нет MX-записей — вы поймаете это на слое проверки домена. Если это известный одноразовый провайдер — это политика.

Знайте части адреса перед валидацией

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

• Локальная часть — всё до @. Здесь живут хитрые случаи: плюс-теги, точки и иногда кавычные строки.
• Доменная часть — всё после @. Она следует правилам меток домена и может быть интернационализирована.

Разделение этих частей делает логику проще для понимания и тестирования.

ASCII vs интернационализированные адреса (вкратце)

Реальные адреса могут содержать не‑ASCII символы в локальной части (EAI) и не‑ASCII домены (IDN). Решите заранее, что вы поддерживаете.

Если вы принимаете только ASCII — отклоняйте не‑ASCII сразу и ясно объясняйте причину. Если вы поддерживаете IDN, обычно вы валидируете домен в его ASCII-совместимой форме (punycode) внутри системы.

Ограничения по длине

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

• Общая длина: 254 символа
• Локальная часть: 64 символа
• Доменная часть: 253 символа
• Каждая метка домена: 63 символа

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

Плюс-адресация и точки: распространённые случаи, которые стоит поддержать

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

Относитесь к + как к нормальному символу в локальной части (за пределами кавычных строк). Даже если некоторые провайдеры игнорируют тег при доставке, он всё равно часть адреса в том виде, как его ввёл пользователь.

Символы локальной части: безопасный набор vs полный набор

Многие команды принимают «безопасный набор» в локальной части (буквы, цифры и немного разделителей, таких как ., _, -, +). Это покрывает большинство реальных адресов и упрощает реализацию.

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

Точки: что позволяет синтаксис (и что делают провайдеры)

В обычной некавычной форме точки разрешены в локальной части, но не везде:

• Нельзя начинать с точки: [email protected] — неверно
• Нельзя заканчивать точкой
• Нельзя использовать подряд две точки: [email protected] — неверно

Не привязывайте синтаксис к поведению провайдеров. Некоторые провайдеры считают firstlast и first.last одним и тем же почтовым ящиком, но это не правило синтаксиса.

Пара быстрых кейсов для тестов:

• [email protected] (плюс-тег)
• [email protected] (точка)
• [email protected] (ведущая точка)
• [email protected] (две точки)
• [email protected] (плюс-тег с субдоменом)

Кавычные строки: тот крайний случай, который упускают большинство парсеров

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

Кавычная локальная часть оборачивается двойными кавычками, например \"john smith\"@example.com. Внутри кавычек пробелы допустимы. Если нужна литеральная двойная кавычка или обратный слеш внутри кавычек, их нужно экранировать обратным слешем.

Запутанность в том, что правила внутри кавычек меняются. Две точки подряд обычно недопустимы в некавычной локальной части, но они разрешены внутри кавычной строки. Значит \"a..b\"@example.com может быть валидным, в то время как [email protected] — нет.

Для регистрации у вас есть реальный выбор:

• Полностью поддерживать кавычные строки (и тестировать их тщательно), или
• Отклонять их намеренно, потому что они редки и могут ломать downstream-системы

Любой вариант защитим. Баги возникают, когда вы случайно отклоняете их из‑за регекса, на который не рассчитывали.

Тест-кейсы, синтаксически валидные:

• \"john smith\"@example.com
• \"a..b\"@example.com
• \"john\\\"smith\"@example.com
• \"back\\\\slash\"@example.com
• \"weird()[],:;\u003c\u003e@\"@example.com

Кавычные строки влияют только на локальную часть. Домен всё равно нужно валидировать отдельно.

Домены и субдомены: что разрешать и что блокировать

Многие валидаторы некорректно обрабатывают домены. Субдомены — нормальная и распространённая вещь. [email protected] не должен удивлять ваш парсер.

Простой подход — валидировать домен как набор меток, разделённых точками, и применять несколько простых правил.

Что разрешать (и почему)

Для большинства потребительских регистраций эти правила хорошо работают:

• Несколько меток (субдомены) допустимы.
• Метки могут содержать буквы и цифры и могут включать дефисы внутри (но не на краях).
• Длина метки от 1 до 63 символов, а общий домен не слишком длинный (часто ограничение — 253).

Требовать «как минимум одну точку» часто полезно как фильтр опечаток для публичных адресов, но это уже политическое решение, если вы поддерживаете внутренние домены.

Что блокировать (распространённые «выглядит хорошо» ошибки)

Проблемы с точками и разбиением скрывают баги. Это жёсткие ошибки:

• Последовательные точки: [email protected]
• Ведущая или конечная точка: [email protected], [email protected].
• Пустые метки из-за плохого разбиения: [email protected]
• Метка начинается или заканчивается дефисом: [email protected], [email protected]
• Недопустимые символы в метке (например, подчёркивания): a@sub_domain.example

Распространённые ошибки парсинга, создающие ложные отклонения

Большинство «недопустимый адрес» ошибок вызвано валидаторами, которые делают допущения вместо последовательных правил.

Пробелы — одна из больших проблем. Копирование/вставка может добавить ведущие пробелы, завершающие пробелы, табы, неразрывные пробелы или скрытый перевод строки. Если валидировать до обрезки — вы отклоните валидный адрес. Если «нормализовать» слишком агрессивно (например, удалять все пробелы внутри), вы можете изменить смысл адреса.

Ещё одна ловушка — наивное разбиение по @. Нужен ясный принцип: ровно один разделитель @, минимум по одному символу с каждой стороны. Не принимайте мусор, разделяя по первому @ и игнорируя остальные, и не падайте с ошибкой, разделяя по всем @.

Некоторые библиотеки частично поддерживают возможности RFC вроде комментариев (например john.smith(comment)@example.com). Частичная поддержка хуже, чем последовательное отклонение, потому что создаёт несоответствия между frontend и backend.

Сигналы тревоги:

• Обрезка только ASCII-пробелов, но не табов, неразрывных пробелов или завершающих переводов строки
• Разбиение по @ без проверки «ровно один»
• Прием с либеральным регексом, а затем падение позже с неопределённой ошибкой
• Различия между окружениями (веб vs мобильное приложение vs бэкенд)
• Игнорирование визуально похожих Unicode-символов (например кириллической «а», похожей на латинскую «a")

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

По шагам: как построить надёжный синтаксический валидатор

Надёжный валидатор — это не одно хитрое правило. Это небольшой набор правил, примененных в правильном порядке.

1) Очистите ввод

Обрежьте начальные и конечные пробелы, затем отклоняйте управляющие символы (табы, переводы строки, нулевые байты). Решите, как обращаться с неразрывными пробелами и прочими странными Unicode-пробелами. Ясно укажите, поддерживаете ли вы не‑ASCII.

2) Парсите с помощью парсера, который понимает RFC (не только регекс)

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

Отделяйте парсинг от политики. Парсер отвечает на вопрос «синтаксически валиден?», политика — «разрешаем ли в продукте?».

3) Примените лимиты и правила меток домена

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

4) Задайте политику строгости и зафиксируйте её

Создайте сознательное решение по крайним случаям вроде кавычных локальных частей. Если вы блокируете их — зафиксируйте это и показывайте понятную ошибку. Если поддерживаете — добавьте тесты для экранированных символов и пробелов.

И самое важное: используйте одинаковые правила на вебе, в мобильном приложении и на бэкенде, чтобы пользователи не сталкивались с несоответствиями.

5) Логируйте неудачи с кодами причин

Когда служба поддержки спрашивает, почему email отклонён, ответ «invalid» бесполезен. Логируйте набор кодов причин (например: CONTROL_CHAR, PARSE_FAIL, LENGTH, DOMAIN_LABEL). Это упрощает диагностику и помогает находить проблемы вроде того, что iOS‑клавиатура вставляет скрытый перевод строки.

Набор тестов, который стоит включить в suite

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

Примеры, которые должны проходить:

• [email protected]
• [email protected]
• [email protected]
• [email protected]
• [email protected]

Примеры, которые должны отклоняться:

• `` (пустая строка)
• plainaddress (нет @)
• alex@ (нет домена)
• @example.com (нет локальной части)
• [email protected] (две точки в локальной части)

Если вы поддерживаете кавычные строки, добавьте явные тесты вроде \"john..doe\"@example.com и \"john\\\"doe\"@example.com. Если вы не поддерживаете их — всё равно держите такие тесты, но отметьте их как отклоняемые по политике, чтобы выбор был виден.

Не ограничивайтесь pass/fail. Храните ожидаемые коды причин, чтобы ошибки были осмысленными.

{ \"input\": \"[email protected]\", \"expected\": \"fail\", \"reason\": \"LOCALPART_DOT_SEQUENCE\" }

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

Быстрый чеклист и следующие шаги

Если вы хотите меньше багов с регистрациями и меньше обращений «почему этот email не проходит?», держите правила синтаксиса короткими и последовательными. Практический минимум выглядит так:

• Ровно один @, минимум по одному символу по обе стороны
• Нет пробелов и управляющих символов (если вы явно не поддерживаете кавычные локальные части)
• Длины в пределах практических лимитов (локальная часть до 64, весь адрес до 254)
• Домен корректно сформирован (нет последовательных точек, нет пустых меток, метки не начинаются и не заканчиваются дефисом)
• Плюс-теги и субдомены по умолчанию разрешены

Примите одно решение и зафиксируйте его: принимать ли кавычные локальные части вроде \"john smith\"@example.com. Они допустимы по RFC 5322, но редки при регистрациях и часто неправильно обрабатываются последующими системами.

После синтаксической проверки добавьте то, что синтаксис покрыть не может: проверьте существование домена, MX-записи и фильтры одноразовых email и ловушек спама. Если вы не хотите сами поддерживать эти уровни, Verimail (verimail.co) — API для валидации email, который сочетает синтаксические проверки с проверкой домена, MX lookup и сопоставлением блоклистов и одноразовых провайдеров, чтобы вы могли держать логику регистрации последовательной, не нагружая один регекс.