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

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

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

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

В дополнение к символам ASCII с 2012 года вы можете использовать вышеупомянутые международные символыU+007F , закодированные как UTF-8, как описано в спецификации RFC 6532 и объяснено в Википедии . Обратите внимание, что по состоянию на 2019 г. эти стандарты все еще помечены как предлагаемые, но постепенно внедряются. Изменения в этой спецификации по существу добавили международные символы в качестве допустимых буквенно-цифровых символов (atext), не затрагивая правила для разрешенных и запрещенных специальных символов, таких как !#и @:.

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

domainЧасть определяется следующим образом :

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

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

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

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

Я сам ничего не знал об этой разработке, пока не вернулся в Японию и не начал видеть адреса электронной почты, такие как hei @ や る .ca и URL-адреса Amazon, например:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ス - デ ジ タ ル カ メ ラ - ポ ー タ ブ ル オ ー デ ィ オ / б / исх = topnav_storetab_e т.е. = UTF-8 & узел = 3210981

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

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

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

Формат адреса электронной почты: local-part@domain-part(не более 64 @ 255 символов, всего не более 256).

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

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

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

Доменная часть:

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

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

• prettyandsimple@example.com
• very.common@example.com
• disposable.style.email.with+symbol@example.com
• other.email-with-dash@example.com
• x@example.com (однобуквенная локальная часть)
• "much.more unusual"@example.com
• "very.unusual.@.unusual.com"@example.com
• "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
• example-indeed@strange-example.com
• admin@mailserver1 (локальное доменное имя без домена верхнего уровня)
• #!$%&'*+-/=?^_`{}|~@example.org
• "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
• " "@example.org (пробел между кавычками)
• example@localhost (отправлено с локального хоста)
• example@s.solutions(см. Список интернет-доменов верхнего уровня )
• user@com
• user@localserver
• user@[IPv6:2001:db8::1]

И эти примеры недействительны:

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

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

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

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

Полное регулярное выражение для адресов RFC2822 составило всего 3.7k.

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

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

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

Связанные с:

• Истинная сила регулярных выражений

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

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

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

Кроме того, допускаются строки в кавычках (например, «John Doe» @ example.com), что позволяет использовать символы, которые в противном случае были бы запрещены, однако они не встречаются в обычной практике. RFC 5321 также предупреждает, что «узлу, который ожидает получать почту, СЛЕДУЕТ избегать определения почтовых ящиков, для которых локальная часть требует (или использует) форму Quoted-string».

Google делает интересную вещь с их адресами gmail.com. Адреса gmail.com допускают только буквы (az), цифры и точки (которые игнорируются).

например, pikachu@gmail.com совпадает с pi.kachu@gmail.com, и оба адреса электронной почты будут отправлены в один и тот же почтовый ящик. PIKACHU@gmail.com также доставляется в тот же почтовый ящик.

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

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

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

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

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

Имя:

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

Сервер:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

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

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

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

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

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

Хорошее чтение по этому вопросу .

Выдержка:

These are all valid email addresses!

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

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

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

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

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

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

  Abc\@def@example.com

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

  Fred\ Bloggs@example.com

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

  Joe.\\Blow@example.com

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

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

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

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

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

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

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

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

Как и другие, я отправляю регулярное выражение для 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до z;

• цифры 0до 9;

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

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

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

• комментарии допускаются с круглыми скобками в конце локальной части; например, john.smith(comment)@example.comи (comment)john.smith@example.comоба эквивалентны john.smith@example.com.

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

Строка в кавычках может существовать как разделенная точками сущность в локальной части, или она может существовать, когда самые внешние кавычки являются крайними символами локальной части (например, abc."defghi".xyz@example.comили "abcdefghixyz"@example.comразрешены. И наоборот, abc"defghi"xyz@example.comнет; ни есть abc\"def\"ghi@example.com). Строки и символы в кавычках, однако, обычно не используются. RFC 5321 также предупреждает, что «узлу, который ожидает получать почту, СЛЕДУЕТ избегать определения почтовых ящиков, для которых локальная часть требует (или использует) форму Quoted-string».

Локальная часть postmasterобрабатывается специально - она ​​не учитывает регистр и должна быть отправлена ​​администратору электронной почты домена. Технически все остальные локальные части чувствительны к регистру, поэтому jsmith@example.comи JSmith@example.comуказывают разные почтовые ящики; однако многие организации рассматривают прописные и строчные буквы как эквивалентные.

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

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

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

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

только три пропущенных символа в этом описании используются в домене-литерале []для формирования пары в кавычках \и символа пробела (% d32). При этом используется весь диапазон 32-126 (десятичный). Аналогичные требования появляются как «qtext» и «ctext». Многие управляющие символы также разрешены / использованы. Один список таких контрольных символов приведен в разделе 4.1 RFC 5322 на стр. 31 как 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 ....

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

Для простоты я очищаю отправку, удаляя весь текст в двойных кавычках и связанные с ними двойные кавычки перед проверкой, добавляя кибошу при отправке адресов электронной почты на основе того, что запрещено. Тот факт, что кто-то может иметь Джона ... "* $ hizzle * Bizzle" .. Адрес Doe@whever.com не означает, что я должен разрешить его в моей системе. Мы живем в будущем, где, возможно, потребуется меньше времени, чтобы получить бесплатный адрес электронной почты, чем делать хорошую работу, вытирая задницу. И это не так, как если бы критерии электронной почты не были намазаны прямо рядом со входом, говоря, что есть, а что нельзя.

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

Недопустимое:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

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

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

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

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

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

Редактировать: Этот ответ продолжал быть темным за то, что был "плохим", и возможно это это заслужило Может быть, это все еще плохо, а может и нет.

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

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[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'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

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

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

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

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