Почта с кириллицей: домен и имя ящика — разные проверки

Кириллица после знака @ и кириллица перед ним — разные случаи для почтового приложения. Сайт может правильно обработать доменное имя, но не поддерживать международное имя ящика на дальнейшем маршруте. Поэтому ответ «мы разрешили русские буквы в форме» ещё не означает, что письмо будет отправлено и доставлено. Проверять нужно весь согласованный путь адреса, не заменяя его части наугад.

Для объяснения используем только учебные строки info@пример.example и отдел@пример.example. Домен example предназначен здесь для примеров; письма по этим адресам отправлять не нужно. Они показывают различие структуры, а не существующие ящики. Испытания доставки проводят отдельно на разрешённых тестовых адресах, которыми управляют участники проверки.

Сравните две части одного адреса

У info@пример.example имя ящика записано латиницей, а доменная часть содержит кириллицу. У отдел@пример.example кириллица есть также в имени ящика. Одинаковый внешний вид «почты на русском» скрывает разные требования. Не принимайте решение о поддержке по одному скриншоту поля без раздельного описания частей.

Стандарт IDNA в RFC 5890 определяет представления международных доменных меток, включая Unicode-форму и ASCII-форму A-label. Это относится к доменной части. Преобразование домена не является способом автоматически превратить произвольное кириллическое имя ящика в другой ASCII-адрес с тем же назначением.

Для международной почты RFC 6531 описывает расширение SMTPUTF8. Поддержку нужно учитывать в почтовом маршруте, когда она требуется адресом или сообщением. Наличие международного домена само по себе не доказывает поддержку всех вариантов ящиков, заголовков и участвующих систем. Форму, приложение и почтовое подключение проверяют согласованно.

Последняя строка не является автоматическим исправлением второй. Транслитерация меняет значение имени ящика. Без подтверждения владельца нельзя считать, что письмо попадёт тому же получателю. Внутренние удобства программы не должны незаметно создавать другой адрес.

Проверьте, что форма действительно отправила приложению

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

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

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

Домен сохраняет понятное представление

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

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

Также не обещайте универсальное исправление всех визуально похожих символов. Если человек ошибся при вводе, догадка программы может изменить получателя. Лучше показать проверяемое значение и дать возможность исправить его осознанно. Удобство формы не должно скрывать тот адрес, который фактически используется для последующей связи.

Приём строки и отправка письма — отдельные результаты

Зелёная отметка возле поля означает только результат согласованной проверки ввода. Запись в CRM подтверждает сохранение адреса. Успешная передача письма выбранному почтовому узлу — другой этап. Получение в контролируемом ящике — ещё один наблюдаемый результат. Не объединяйте эти подтверждения одним сообщением «адрес работает».

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

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

Альтернативный адрес спрашивают, а не придумывают

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

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

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

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

Приёмка по небольшой матрице

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

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

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

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