Формат электронной почты выглядит простым: имя, значок «собака», домен. Но стоит заглянуть в правила, и оказывается, что стандарт разрешает гораздо больше, чем принимает любая привычная почтовая служба. Разберём, из чего состоит адрес, какие у него пределы длины и почему «правильно по стандарту» и «работает на практике» — не одно и то же.
Из чего состоит адрес
Символ «собака» делит адрес на две части. Слева стоит имя получателя внутри домена, справа — сам домен. Левая часть уникальна только внутри своего домена, поэтому два одинаковых имени на разных доменах принадлежат разным людям.
Правая часть — это доменное имя. Оно тоже не монолит: домен состоит из уровней, разделённых точками, от самого узкого слева к самому общему справа. Правила для доменов приходят из общей системы имён и не зависят от почты.
Практический вывод из этого устройства один: проверять адрес целиком — бессмысленно. Левая и правая части подчиняются разным правилам, и любая единая проверка будет либо слишком строгой, либо слишком мягкой.
Какие пределы длины установлены
Международный стандарт задаёт пределы для каждой части и для адреса целиком.
| Что именно | Предел по стандарту |
|---|---|
| Имя получателя до знака «собака» | 64 байта |
| Домен после знака «собака» | 255 байт |
| Адрес целиком, включая угловые скобки | 256 байт |
Байт — не то же самое, что знак. Если адрес содержит символы за пределами базового латинского набора, каждый такой знак занимает больше одного байта, поэтому запас по длине на глаз определить нельзя. Адрес из шестидесяти русских букв слева формально близок к пределу, хотя выглядит коротким.
Отдельно стоит сказать про распространённое расхождение. Многие службы ограничивают адрес целиком более строго, чем стандарт, — это сложившаяся инженерная привычка, а не требование стандарта. Поэтому адрес, который по правилам допустим, вполне может быть отклонён при регистрации.
Что стандарт разрешает, а службы не принимают
Самый интересный разрыв между правилами и практикой — в левой части адреса.
Стандарт допускает имя в кавычках, если внутри есть пробелы или специальные знаки. Допускает пояснения в скобках, которые технически не являются частью адреса. Допускает запись домена в виде числового адреса в квадратных скобках. И, в расширениях для международных имён, допускает знаки национальных алфавитов.
На практике почти ничего из этого не работает. Формы в интернете рассчитаны на простой набор: латинские буквы, цифры, точка, дефис, подчёркивание — и всё. Кавычки и скобки отклоняются как ошибка, числовой домен тоже, а адрес с национальными знаками принимается далеко не везде, даже если технически может быть доставлен.
Этот разрыв объясняет большую часть споров о валидации. Строгая проверка, написанная по стандарту, отклоняет то, что человек считает нормальным. Слишком мягкая пропускает то, что потом не сработает. Правило, которое хорошо работает на практике: принимать чуть больше, чем разрешено, и не отказывать по формальным признакам, если пользователь не может исправить адрес сам.
Почему нельзя проверять адрес слишком строго?
Потому что любая избыточно строгая проверка отклоняет настоящие адреса, и человек уходит, не поняв, в чём дело.
Типичные примеры. Запрет на знак плюс в левой части: многие службы используют его для разделения адресов, и такие адреса вполне рабочие. Запрет на несколько точек подряд или на точку в начале: стандарт действительно запрещает такое, но отклонять по этому признаку нужно с понятным сообщением. Требование непременно двух уровней в домене: есть рабочие адреса и с одним, и с большим числом уровней.
Отдельная ошибка — считать адрес нечувствительным к регистру целиком. В домене регистр действительно не важен. В левой части стандарт формально разрешает службе различать регистр, хотя почти все на практике его игнорируют. Хранить адрес лучше так, как его ввёл человек, а сравнивать — приведённым к одному регистру; это безопаснее, чем менять введённое значение.
Как не задеть своих пользователей?
Если вы отвечаете за поле ввода адреса, начните с того, что должна делать проверка. Она нужна, чтобы поймать очевидную опечатку и не отправить письмо в никуда. Всё остальное — не её работа: существует ли адрес на самом деле, проверяется отправкой письма, а не разбором строки.
Практические советы просты. Не отклоняйте адрес из-за длины, если он укладывается в пределы; если не укладывается — объясните, какая часть слишком длинная. Не считайте кавычки, скобки и знак плюс признаком подделки: если вам такие адреса не нужны, просто сообщите об ограничении прямо. И обязательно показывайте, что именно не понравилось в вводе, — сообщение «неверный адрес» одинаково бесполезно и для опечатки, и для нестандартной записи.
И последнее: адрес, который вы используете для проверок, — тестовый. Он нужен, чтобы испытать форму и рассылку, а не чтобы выдать себя за реального человека.
Что важно разработчику: пределы полей и нелатинские адреса
Первое — задайте предел поля по стандарту, а не по привычке. Хранилищу и полю ввода подходит 256 байт для адреса целиком; урезать его до привычных коротких значений — значит заранее отбрасывать допустимые адреса. Помните, что байты и знаки расходятся, поэтому предел лучше считать по длине в байтах, а не по числу символов на экране.
Второе — принимайте международные адреса, но не полагайтесь на них. Стандарт допускает знаки национальных алфавитов, однако поддержка у служб разная. Разумное поведение: не отклонять такой адрес у себя, но предупредить пользователя, что часть служб может его не принять, и предложить альтернативу. Молчаливая нормализация здесь опасна: если вы преобразуете знаки, адрес может перестать совпадать с тем, на который человек получает почту.
Третье — не смешивайте разбор и доставку. Синтаксическая проверка подтверждает только форму записи. Она не говорит, существует ли адрес, работает ли домен и принимает ли он письма. Путать эти вещи в сообщениях интерфейса не стоит: пользователь, увидевший «адрес проверен», будет ждать письма, которого не будет.
Четвёртое — тестируйте границы, а не только обычный случай. Полезно покрыть адрес на пределе длины слева, на пределе справа, адрес с точкой и знаком плюс, адрес с нелатинскими знаками и адрес с лишним пробелом по краям. Пробелы по краям — самая частая причина «неработающего» адреса, и решается она удалением пробелов при вводе, а не сообщением об ошибке. Для таких прогонов удобно брать заведомо разовые адреса: чем они отличаются от постоянных, разбирает материал о разовом ящике и постоянных адресах.
Пятое — не забывайте о выводе. Адрес отображается в письмах, счетах и журналах. Слишком длинный адрес должен корректно переноситься в письме, а не обрезаться. Это мелочь, которая ломает доверие к письму целиком, если получатель видит неполный обратный адрес.
Что делать дальше
Откройте свою форму регистрации и проверьте её на трёх значениях: адрес с точкой и знаком плюс, адрес с нелатинскими знаками и адрес на пределе длины. Если какой-то из них отклоняется, посмотрите формулировку сообщения — она должна объяснять причину. Для ручной проверки получите адрес через временную почту и посмотрите, как выглядит введённое значение в письме. О том, как проверять сам сценарий регистрации, рассказывает материал о тестировании подтверждения почты.