Какие символы допускаются в адресе электронной почты?

Я не спрашиваю о полной проверке электронной почты.

Я просто хочу знать, какие символы разрешены в user-name и server части адреса электронной почты. Это может быть упрощено, возможно, адреса электронной почты могут принимать другие формы, но мне все равно. Я спрашиваю только об этой простой форме: [email protected] (например [email protected]) и разрешенные символы в обеих частях.

18 ответов


посмотреть RFC 5322: формат интернет-сообщений и, в меньшей степени, RFC 5321: простой протокол передачи почты.

RFC 822 также охватывает адреса электронной почты, но имеет дело в основном с его структурой:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

и, как обычно, Википедия имеет приличный статья об адресах электронной почты:

локальная часть адреса электронной почты может использовать любой из этих символов ASCII:

  • прописные и строчные латинские буквы A to Z и a to z;
  • цифры 0 to 9;
  • специальные символы !#$%&'*+-/=?^_`{|}~;
  • точка ., при условии, что он не является первым или последним символом, если он не указан, а также при условии, что он не появляется последовательно, если он не указан (например,[email protected] не допускается "John..Doe"@example.com разрешена);
  • пространство и "(),:;<>@[\] символы разрешены с ограничения (они разрешены только внутри строки с кавычками, как описано в абзаце ниже, и кроме того, обратной косой черте или двойной кавычке должна предшествовать обратная косая черта);
  • комментарии разрешены с круглыми скобками на любом конце локальной части; например john.smith(comment)@example.com и (comment)[email protected] оба эквивалентно [email protected].

в дополнение к символам ASCII,в 2012 году вы можете использовать international символы выше U+007F, закодированных как UTF-8.

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

на domain это следующим образом:

интернет-стандарты (запрос комментариев) для протоколов предписывают, что метки имени хоста компонента могут содержать только буквы ASCII a через z (без учета регистра), цифры 0 через 9, и дефис (-). Исходная спецификация имен хостов в RFC 952, предписано, что метки не могут начинаться с цифры или дефиса и не должны заканчиваться дефисом. Однако последующая спецификация (RFC 1123) разрешенные метки имен хостов начинаются с цифр. Допускаются никакие другие символы, знаки препинания или пробелы.


Берегись! В этом потоке есть куча знаний (вещи, которые раньше были правдой, а теперь нет).

чтобы избежать ложноположительных отклонений фактических адресов электронной почты в текущем и будущем мире и из любой точки мира, вам нужно знать, по крайней мере, концепцию высокого уровня RFC 3490, " интернационализация доменных имен в приложениях (IDNA)". Я знаю, что люди в нас и часто не в курсе этого, но это уже в широко распространенный и быстро увеличение использования по всему миру (в основном на английском преобладают детали).

суть в том, что теперь вы можете использовать такие адреса, как [email protected]日本.com и [email protected]ügen.net - ... Нет, это еще не совместимо со всем, что там (как многие сетовали выше, даже простые qmail-style +ident-адреса часто ошибочно отклоняются). Но есть RFC, есть спецификация, теперь она поддерживается IETF и ICANN, и-что более важно-есть большое и растущее число реализации, поддерживающие это улучшение, которые в настоящее время находятся в эксплуатации.

Я сам мало знал об этом развитии, пока не вернулся в Японию и не начал видеть адреса электронной почты, такие как [email protected]やる.ca и Amazon URLs, как это:

http://www.amazon.co.jp/エレクトロニクス-デジタルカメラ-ポータブルオーディオ/b/ref=topnav_storetab_e?ie=UTF8&node=3210981

Я знаю, что вам не нужны ссылки на спецификации, но если вы полагаетесь исключительно на устаревшие знания хакеров Интернет-форумы, ваш email validator в конечном итоге отклоняет адреса электронной почты, которые не-Enlish пользователи все чаще ожидают работать. Для этих пользователей такая проверка будет такой же раздражающей, как обычная мертвая форма мозга, которую мы все ненавидим, та, которая не может обрабатывать + или трехчастное доменное имя или что-то еще.

поэтому я не говорю, что это не хлопот, но полный список символов "разрешено при некоторых/любых/нет условиях" (почти) все символы на всех языках. Если хочешь ... "примите все действительные адреса электронной почты (и многие недействительные тоже)", тогда вы должны учитывать IDN, что в основном делает подход на основе символов бесполезным (извините), если вы сначала преобразование интернационализированных адресов электронной почты до Punycode.

после этого вы можете следовать (большинству) советов выше.


формате e-mail адрес: [email protected] (макс. [email protected] символов, не более 256 в общей сложности).

на local-part и domain-part может иметь другой набор разрешенных символов, но это еще не все, так как есть больше правил.

в общем, локальная часть может иметь следующие символы ASCII:

  • строчные буквы латинского алфавита: abcdefghijklmnopqrstuvwxyz,
  • заглавные латинские буквы:ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • цифр: 0123456789,
  • специальные символы: !#$%&'*+-/=?^_`{|}~,
  • точка: . (не первый или последний символ или повторяется, если не указано),
  • пробел пунктуации, такие как:"(),:;<>@[\] (С некоторыми ограничениями),
  • комментарии: () (разрешено в скобках, например,(comment)[email protected]).

домен входит:

  • строчные буквы латинского алфавита: abcdefghijklmnopqrstuvwxyz,
  • заглавные латинские буквы: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • цифры: 0123456789,
  • дефис: - (не первый и не последний символ),
  • может содержать IP-адрес в квадратные скобки: [email protected][192.168.2.1] или [email protected][IPv6:2001:db8::1].

эти адреса электронной почты действительны:

и эти примеры некорректны:

  • Abc.example.com (не @ символ)
  • [email protected]@[email protected] (одна @ допускается за пределами кавычек)
  • a"b(c)d,e:f;gi[j\k][email protected] (ни один из специальных символов в этой локальной части не допускается вне кавычек)
  • just"not"[email protected] (строки с кавычками должны быть разделены точкой или единственный элемент, составляющий локальную часть)
  • this is"not\[email protected] (пробелы, кавычки и обратные косые черты могут существовать только в кавычках и перед обратной косой чертой)
  • this\ still\"not\[email protected] (даже если экранировано (предшествует обратной косой чертой), пробелы, кавычки и обратные косые черты должны по-прежнему содержаться кавычками)
  • [email protected] (две точки перед @); (С оговоркой: Gmail позволяет это через)
  • [email protected] (две точки после @)
  • a действительно адрес с ведущим пробелом
  • действительный адрес с конечным пробелом

источник: адрес электронной почты в Википедии


регулярное выражение RFC2822 Perl для проверки электронной почты:

(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:
\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(
?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ 
\t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-
31]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\
](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+
(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:
(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)
?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\
r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[
 \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)
?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t]
)*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[
 \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*
)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t]
)+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*)
*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+
|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r
\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:
\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t
]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1
]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](
?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?
:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?
:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)|(?:[^()<>@,;:\".\[\] 0-1]+(?:(?
:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?
[ \t]))*"(?:(?:\r\n)?[ \t])*)*:(?:(?:\r\n)?[ \t])*(?:(?:(?:[^()<>@,;:\".\[\] 
0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|
\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>
@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"
(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?
:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[
\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*|(?:[^()<>@,;:\".\[\] 0-
1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(
?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)?[ \t])*(?:@(?:[^()<>@,;
:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([
^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\"
.\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\
]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\
[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\
r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 
0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]
|\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?(?:[^()<>@,;:\".\[\] 
00-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\
.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,
;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]]))|"(?
:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*))*@(?:(?:\r\n)?[ \t])*
(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".
\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t])*(?:[
^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\]
]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(?:\r\n)?[ \t])*)(?:,\s*(
?:(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(
?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[
\["()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t
])*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t
])+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?
:\.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|
\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*|(?:
[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".\[\
]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)*\<(?:(?:\r\n)
?[ \t])*(?:@(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["
()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)
?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>
@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*(?:,@(?:(?:\r\n)?[
 \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,
;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\.(?:(?:\r\n)?[ \t]
)*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\
".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*)*:(?:(?:\r\n)?[ \t])*)?
(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\["()<>@,;:\".
\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])*)(?:\.(?:(?:
\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z|(?=[\[
"()<>@,;:\".\[\]]))|"(?:[^\"\r\]|\.|(?:(?:\r\n)?[ \t]))*"(?:(?:\r\n)?[ \t])
*))*@(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])
+|\Z|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*)(?:\
.(?:(?:\r\n)?[ \t])*(?:[^()<>@,;:\".\[\] 0-1]+(?:(?:(?:\r\n)?[ \t])+|\Z
|(?=[\["()<>@,;:\".\[\]]))|\[([^\[\]\r\]|\.)*\](?:(?:\r\n)?[ \t])*))*\>(?:(
?:\r\n)?[ \t])*))*)?;\s*)

полное регулярное выражение для адресов RFC2822 было всего лишь 3.7 k.

Читайте также: парсер адресов электронной почты RFC 822 в PHP.


официальное определения адресов электронной почты находятся в:

  • RFC 5322 (разделы 3.2.3 и 3.4.1, устаревшие RFC 2822), RFC 5321, RFC 3696,
  • RFC 6531 (разрешенные символы).

по теме:


Википедия имеет хорошую статью об этом и официальная спецификация здесь. Из Wikipdia:

локальная часть адреса электронной почты может использовать любой из следующих символов ASCII:

  • заглавные и строчные английские буквы (a-z, A-Z)
  • цифры от 0 до 9
  • символы ! # $ % & ' * + - / = ? ^ _ ' { / } ~
  • символ . (точка, точка, точка) при условии, что это не первый или последний символ, а также при условии, что он не появляется два или более раз подряд.

кроме того, строки с кавычками (т. е. "John Doe" @example.com) разрешены, таким образом, разрешены символы, которые в противном случае были бы запрещены, однако они не появляются в обычной практике. RFC 5321 также предупреждает, что"хост, который ожидает получать почту, должен избегать определения почтовых ящиков, где локальная часть требует (или использует) форму с кавычками".


название:

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

сервер:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

вы можете начать с статья в Википедии:

  • заглавные и строчные английские буквы (a-z, A-Z)
  • цифры от 0 до 9
  • символы ! # $ % & ' * + - / = ? ^ _ ' { / } ~
  • символ . (точка, точка, точка) при условии, что это не первый или последний символ, а также при условии, что он не появляется два или более раз подряд.

Google делает интересную вещь со своими gmail.com адреса. gmail.com адреса разрешают только буквы (a-z), цифры и точки(которые игнорируются).

например, [email protected] это то же самое, что [email protected], и оба адреса электронной почты будут отправлены в один и тот же почтовый ящик. [email protected] также доставляется в тот же почтовый ящик.

поэтому, чтобы ответить на вопрос, иногда это зависит от исполнителя от того, сколько стандартов RFC они хотят следовать. Гугла gmail.com стиль адреса совместим со стандартами. Они делают это таким образом, чтобы избежать путаницы, когда разные люди будут принимать аналогичные адреса электронной почты, например

*** gmail.com accepting rules ***
[email protected]   (accepted)
[email protected]   (bounce and account can never be created)
[email protected]     (accepted)
D.Oy'[email protected]   (bounce and account can never be created)

ссылка Википедии является хорошей ссылкой на то, что адреса электронной почты обычно позволяют. http://en.wikipedia.org/wiki/Email_address


проверьте наличие @ and . а затем отправьте им электронное письмо для проверки.

Я все еще не могу использовать мой .имя адреса электронной почты на 20% сайтов в интернете, потому что кто-то испортил их проверку электронной почты, или потому, что он предшествует новые адреса действительны.


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

для хорошего руководства по адресам, которые вы создаете; см.: http://www.remote.org/jochen/mail/info/chars.html

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


хорошее чтение на вопрос.

выдержка:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\Blow"@example.com
"[email protected]"@example.com
customer/[email protected]
[email protected]
!def!xyz%[email protected]
[email protected]

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

IETF RFC 3696 авторитет по этому вопросу, и следует обращаться в раздел 3. Ограничения на адреса электронной почты на странице 5:

современные адреса электронной почты состоят из "локальной части" отделился от "доменная часть" (полностью квалифицированная доменное имя) по знаку at ("@"). Синтаксис доменной части соответствует синтаксису предыдущей части раздел. Проблемы, выявленные в этом разделе относительно фильтрации и списки имен применяются к доменным именам, используемым в контексте электронной почты как что ж. Доменное имя также может быть заменено IP-адресом в квадратные скобки, но эта форма сильно не рекомендуется, за исключением тестирование и устранение неполадок.

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

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

  Abc\@[email protected]

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

  Fred\ [email protected]

символ обратной косой черты также может использоваться для цитирования себя, например,

  Joe.\[email protected]

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

  "[email protected]"@example.com

  "Fred Bloggs"@example.com

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

без кавычек, local-parts может состоять из любой комбинации
алфавитные символы, цифры или любой из специальных символов

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

точка (".") может также появиться, но не может использоваться для начала или конца локальная часть, а также не может появляться два или более последовательных периода. Указано иначе, любой графический (печатный) символ ASCII, кроме знак at ( " @ " ), обратная косая черта, двойной кавычка, запятая, или квадратные скобки может появиться без цитирования. Если какой-либо из этого списка исключен символы должны появиться, они должны быть процитированы. Такие формы, как

  [email protected]

  customer/[email protected]

  [email protected]

  !def!xyz%[email protected]

  [email protected]

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

как и другие, я отправляю регулярное выражение, которое работает как для PHP, так и для JavaScript для проверки адресов электронной почты:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

как можно найти в это ссылка на Википедию

локальная часть адреса электронной почты может использовать любой из этих символов ASCII:

  • прописные и строчные латинские буквы A до Z и a to z;

  • цифры 0 до 9;

  • специальные символы !#$%&'*+-/=?^_`{|}~;

  • точка ., при условии что это не первый или последний символ, если он не указан, а также при условии, что он не появляется последовательно, если он не указан (например,[email protected] не допускается "John..Doe"@example.com разрешена);

  • космос и "(),:;<>@[\] символы разрешены с ограничениями (они разрешены только внутри строки с кавычками, как описано в абзаце ниже, и, кроме того, обратной косой чертой или двойной кавычкой должна предшествовать обратная косая черта);

  • комментарии разрешено с круглыми скобками на любом конце локальной части; например john.smith(comment)@example.com и (comment)[email protected] оба эквивалентно [email protected].

в дополнение к вышеуказанным символам ASCII, международные символы выше U + 007F, закодированные как UTF-8, разрешены RFC 6531, хотя почтовые системы могут ограничить, какие символы использовать при назначении локальной части.

строка с кавычками может существовать как объект, разделенный точкой в локальной части, или может существуют, когда самые внешние кавычки являются самыми внешними символами локальной части (например,abc."defghi"[email protected] или "abcdefghixyz"@example.com разрешено. И наоборот, abc"defghi"[email protected] нет, ни abc\"def\"[email protected]). Однако кавычки и символы обычно не используются. RFC 5321 также предупреждает ,что"хост, который ожидает получать почту, должен избегать определения почтовых ящиков, где локальная часть требует (или использует) форму с кавычками".

местная часть postmaster обработано специально-оно регистр не учитывается и должен быть перенаправлен администратору электронной почты домена. Технически все остальные локальные части чувствительны к регистру, поэтому [email protected] и [email protected] укажите разные почтовые ящики; однако многие организации рассматривают заглавные и строчные буквы как эквивалентные.

несмотря на широкий спектр специальных символов, которые технически действительны; организации, почтовые службы, почтовые серверы и почтовые клиенты на практике часто не принимают их все. Например, Windows Live Hotmail позволяет создавать адреса электронной почты только с помощью буквенно-цифровых символов, dot (.), подчеркивание (_) и дефис (-). Общие рекомендации избегать использования некоторых специальных символов, чтобы избежать риска отклоненных писем.


ответ (почти) ALL (7-битный ASCII).
Если правила включения"...допускается при некоторых/любых/никаких условиях..."

просто взглянув на одно из нескольких возможных правил включения для разрешенного текста в части "текст домена" в RFC 5322 в верхней части страницы 17 мы находим:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

только три недостающих символа в этом описании используются в domain-literal [], чтобы сформировать цитируемую пару \ и Пробел (%d32). При этом используется весь диапазон 32-126 (десятичный). Аналогичное требование отображается как "qtext"и " ctext". Многие управляющие символы также разрешены / используются. Один список таких символов управления отображается на стр. 31 раздел 4.1 RFC 5322 как obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

все эти управляющие символы разрешены, как указано в начале раздела 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

и поэтому такое правило включения является "слишком широким". Или, в другом смысле, ожидаемое правило "слишком упрощенно".


в моем PHP я использую эту проверку

<?php
if (preg_match(
'/^(?:[\w\!\#$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~][email protected](?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'[email protected]"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

попробуйте сами http://phpfiddle.org/main/code/9av6-d10r


Я создал это регулярное выражение в соответствии с рекомендациями RFC:

^[\w\.\!_\%#\$\&\'=\?\*\+\-\/\^\`\{\|\}\~][email protected](?:\w+\.(?:\w+\-?)*)+$

для тех, кто заинтересован в проверке международных доменов, здесь доступен инструмент .NET (не связанный с компанией):

http://cobisi.com/email-validation/.net-component - совместимый с длинным списком RFCs:

стандарты IETF (RFC 1123, RFC 2821, RFC 2822, RFC 3490, RFC 3696, RFC 4291, RFC 5321, RFC 5322 и RFC 5336), с поддержкой цитируемых слов, литералы домена, не-ASCII доменные имена (IDNA) и почтовые ящики, и комментарии


для простоты Я дезинфицирую представление, удаляя весь текст в двойных кавычках и связанные с ними двойные кавычки перед проверкой, помещая кибош на отправку адресов электронной почты на основе того, что запрещено. Просто потому, что у кого-то может быть Джон.. "The * $hizzle * Bizzle" [email protected] адрес не означает, что я должен разрешить это в моей системе. Мы живем в будущем, где, возможно, требуется меньше времени, чтобы получить бесплатный адрес электронной почты, чем сделать хорошую работу торец. И это не так, как если бы критерии электронной почты не были оштукатурены рядом с входом, говорящим, что разрешено, а что нет.

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

запрещены:

    local part starts with a period ( [email protected] )
    local part ends with a period   ( [email protected] )
    two or more periods in series   ( [email protected] )
    &’`*|/                          ( some&thing`[email protected] )
    more than one @                 ( [email protected]@host.com )
    :%                              ( mo:characters%mo:[email protected] )

в приведенном примере:

John.."The*$hizzle*Bizzle"[email protected] --> [email protected]

[email protected] --> [email protected]

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

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

Я не разрешаю вонючие письма в моей системе, возможно, это просто выбрасывание денег. Но в 99,9% случаев люди просто делают правильные вещи и имеют электронную почту, которая не подталкивает пределы соответствия к краю, используя сценарии совместимости edge case. Будьте осторожны с regex Ддос, это место, где вы можете попасть в беду. И это связано с третьей вещью, которую я делаю, я устанавливаю ограничение на то, как долго я готов обрабатывать любое письмо. Если ему нужно замедлить мою машину, чтобы получить проверку-это не проходит мимо моей логики конечной точки API входящих данных.

Edit: этот ответ продолжал получать dinged за то, что он "плохой", и, возможно, он этого заслуживал. Может, все еще плохо, а может, и нет.


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