Можно ли ввести некорректный email?

Что проверяют

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

Как отвечать

Разделите три уровня: ввод в поле, синтаксическая проверка, проверка существования. Синтаксис проверяют на клиенте и обязательно на сервере. Существование подтверждается только письмом со ссылкой: valid@example.com синтаксически верен, но такого ящика может не быть.

Негативные случаи:

• структура: нет @, два @, пустая локальная часть или домен (@example.com, user@);
• точки: в начале или конце локальной части, две подряд (user..name@example.com, user@example..com);
• домен: метка начинается или кончается дефисом, метка длиннее 63 символов;
• пробелы и спецсимволы: пробел внутри без кавычек, запятая, угловые скобки;
• безопасность: строки с <script>, SQL-инъекцией, переводом строки (инъекция заголовков письма).

Позитивные случаи, которые часто ломаются: user+tag@example.com, o'brien@example.com, заглавные буквы, поддомены вроде a@mail.corp.example.com, кириллический домен user@пример.рф, пробелы по краям, которые система должна обрезать, а не отвергать.

Упомяните, что встроенная проверка input type="email" в HTML сознательно проще RFC 5322 и, например, принимает user@localhost без точки в домене.

Где спотыкаются

Называют некорректными адреса, которые на самом деле валидны. user@domain без точки синтаксически допустим, user@domain.c построен правильно, просто такой зоны нет. Принимать ли их, решает бизнес-правило, а не стандарт.

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

Смотрят только на сообщение об ошибке в интерфейсе и не отправляют тот же адрес через API в обход фронтенда.