Skip to Content

Валидация E-mail адреса. Читаем RFC

По мотивам статьи "I Knew How To Validate An Email Address Until I Read The RFC" Phil Haack

 В ваши руки, в сто-пятисотый раз попал валидатор e-mail адреса. Вы лениво потянулись, неспешно вспоминая, как должен этот адрес выглядеть, мысленно отметили, что в нем должны быть:

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

Вы не глядя тянетесь к клавиатуре, без проблем нащупываете комбинацию клавиш Shift + 2, дважды нажимаете ее... и открываете баг трекер...

Стоп.

А почему вы решили, что ваши "абв" правильные? Вы где-то об этом прочитали? Можете ткнуть пальцем в нормативный документ? Нет? И уже не слишком уверены в своей правоте? Тогда давайте попробуем разобраться вместе, но для начала немного ликбеза.

Ликбез

Как вы знаете, а может и не знаете, многие вещи в интернете пока не стандартизированы. Но есть люди, которые страсть как любят всякие нормативные документы, и жить без них не могут. Поэтому они начинают писать их сами, а потом объединяются в различные сообщества и пишут их уже мелкими группами по несколько сотен человек. Ярким примером подобной организации является Internet Society или ISOC, которая публикует информационные документы формата RFC (Request for Comments). Стоит отметить, что вклад этой организации в развитие интернета трудно переоценить. Хотя документы RFC и не являются официальными стандартами, но многие на это плев ,несмотря на это, они широко применяются интернет сообществом, заменяя недостающие стандарты. Короче говоря, это именно те документы, из которых рождаются Best Practices и прочая...

Больше по этому поводу мне сказать нечего. Самых любопытных стоит отравить в Википедию и на сопутствующие ресурсы, а мы вернемся к нашим баранам, то бишь к адресам.

Итак, давайте взглянем на RFC. И начнем мы с RFC 2821. Этот документ называет (раздел 2.3.10) часть адреса до @, локальной частью (local part) и говорит нам о том, что:
 

Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.

То есть, локальная часть e-mail адреса должна интерпретироваться (читай, валидироваться) только почтовым сервером на стороне хоста указанного после @. Уже интересно, не правда ли?
Теперь давайте обратимся к документу RFC 2822, который рассматривает адреса электронной почты более подробно. Раздел 3.4.1 этого документа гласит, что:

An addr-spec is a specific Internet identifier that contains a locally interpreted string followed by the at-sign character ("@",ASCII value 64) followed by an Internet domain. The locally interpreted string is either a quoted-string or a dot-atom.

Что же такое dot-atom? Ответ на этот вопрос содержится в разделе 3.2.4 этого же документа. Dot-atom - строка состоящая из atoms  разделенных точками, а atoms, в сою очередь, - это любые буквы и цифры латинского алфавита, а также (внимание!) символы:

! $ & * - = ^ ` | ~ # % ' + / ? _ { }

Более того, как вы могли заметить, в разделе 3.4.1 говорилось о quoted-string, т.е. о возможности использовать вообще любые символы в локальной части адреса, при условии, что они экранированы обратным слешем или окружены двойными кавычками.
Ну и напоследок, давайте заглянем в документ RFC 3696 в третьем разделе которого мы обнаружим подтверждения наших изысканий: 

Without quotes, local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters
! # $ % & ' * + - / = ? ^ _ ` . { | } ~

 Здесь же мы найдем и несколько примеров адресов электронной почты (держитесь крепче, все приведенные ниже адреса - валидны): 

Abc\@def@example.com
Fred\ Bloggs@example.com
Joe.\\Blow@example.com
"Abc@def"@example.com
"Fred Bloggs"@example.com
user+mailbox@example.com
customer/department=shipping@example.com
$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

Вот собственно и все...

Задумались?

Я тоже...

 

+++++++---

Мощное изыскание. Но выводы

Мощное изыскание.

Но выводы где? Такие фельетоны не должны заканчиваться безмолвными троеточиями, я не Шлиман. Я требую продолжения.

Во-вторых, что немцу закон, то русским бессмысленные буквосочетания.

Составим валидный "по RFC" логин на известном почтовом сервисе:

Кто прав?

Прав админ сервера, а не кто-то из хз какой стандартизующей организации.

Если админ сервера считает, что мой прекрасный логин не валиден, то что ему тыкание в стандарты?

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

 Выводы? А каких вы ждете

 Выводы? А каких вы ждете выводов? Это была информация к размышлению, а выводы каждый сделает для себя сам. 

Что касается вашего комментария, то мне, если честно, не очень понятны некоторые моменты:

 1.

Прав админ сервера, а не кто-то из хз какой стандартизующей организации.

Вы считаете ISOC "хз какой-то организацией"? Странно, а разработчики то и не в курсе... Smile

Если вы внимательно прочли статью, и сходили по ссылкам, то могли заметить, что RFC 2821 носит название Simple Mail Transfer Protocol и, вообщем то, является спецификацией протокола SMTP.

А если смотрели на эти документы еще внимательнее, то могли увидеть, что люди написавшие их имеют непосредственное отношение к таким организациям как: AT&T Laboratories и QUALCOMM Incorporated. И правда, "хз какие организации" Smile

2. Как понятно из поста и сопутствующих документов адрес "Ast@enix@@yourdomain.com не валиден даже по RFC. Как минимум он должен выглядеть как "Ast@enix@"@yourdomain.com.

3. Странно, что вы не разделяете понятий веб интерфейса и мейл сервера. В веб интерфейсе наворотить можно, что угодно, что с успехом делают на mail.ru да и на большинстве почтовых сервисов (кстати, на некоторых даже "_" не в почете). Зачем это делают - уже другой вопрос. Скорее всего, чтобы упростить себе жизнь, исключив проблемы с БД и прочий гемо прочие неприятности. А вот, если бы вы попытались воспользоваться мейл сервером напрямую, т.е. через SMTP, то с удивлением бы обнаружили, что большую часть адресов приведенных в статье он проглотил бы не поперхнувшись (между прочим, яндекс добрую часть этих адресов принимает и через веб интерфейс). 

Кстати говоря, перед тем как писать этот пост я провел эксперимет. Просто не хотелось его нагромождать лишней информацией, но раз вы настаиваете Smile Результаты эксперимента ниже (картинки кликабельны).

Что делаем?

Отправляем письмо на  мейл сервер по SMTP с адресом получателя user+mailbox@iqa.com.ua (валидный по RFC, но его не существует на сервере)

Что получаем?

Т.е. "Неизвестный пользователь". Обратите внимание - не неправильный формат адреса или что-либо подобное, а именно неизвестный пользователь.

Что делаем?

Отправляем письмо на  мейл сервер по SMTP с адресом получателя department@iqa.com.ua (вроде как валидный по всем параметрам, но тоже не существующий на сервере)

Что получаем?

 

Что и требовалось доказать. Ошибка одна и та же, независимо от "валидности" адреса.

Но все равно выглядит как-то неубедительно... Ну что ж, сделаем иначе.

Что делаем?

Ставим SMTP сервер на свой ПК (я использовал Courier Mail Server). И создаем там ящики с адресами user+mailbox@localhost, $A12345@localhost. Создаем учетные записи в любимом почтовом клиенте. Отправляем писмо. Смотрим логи сервера...

Что получаем?

Здорово! Проверим-ка свой ящик.

0_o. Что это? Неужели письмо? Smile

Мне кажется, что этого достаточно. Думаю, что самые любопытные давно это проделали сами.

 4.

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

Каюсь, но всю глубину мысли не понял. Smile

За сим разрешите откланяться.

 

Классные выводы, спасибо за

Классные выводы, спасибо за статью, Vader!

Вроде и было написано "То

Вроде и было написано "То есть, локальная часть e-mail адреса должна интерпретироваться (читай, валидироваться) только почтовым сервером на стороне хоста указанного после @.".  Как говорится, "хозяин-барин", и он же указывает критерии валидности...

Не разрешаю откланяться

Не разрешаю откланяться Smile

Прошу писать еще в том же духе и на другие темы.

Не тормози на полпути.

Тем не менее популярные

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

Благодаря умникам, которые

Благодаря умникам, которые прописывают валидацию почты, я имея адрес gaur-@mail.ru не могу с ним зарегиться чуть ли не на половине сайтов.

И я такой точно не один...

Вопрос - максимальная длинна

Вопрос - максимальная длинна адреса имеет ограничения?

Все тот же RFC говорит о том,

Все тот же RFC говорит о том, что

local-part
 The maximum total length of a user name or other local-part is 64 characters. 

и

domain
 The maximum total length of a domain name or number is 255 characters. 

Отправить комментарий

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступны HTML теги: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.
  • Pairs of<blockquote> tags will be styled as a block that indicates a quotation.
  • Textual smileys will be replaced with graphical ones.

Подробнее о форматировании