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

Question

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Чтобы избежать ложноположительных отклонений фактических адресов электронной почты в текущем и будущем мире и из любой точки мира, вам необходимо знать хотя бы концепцию высокого уровня 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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

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

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

---

Связанные с:

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

  Abc\@[e-mail]

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

  Fred\ [e-mail]

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

  Joe.\\[e-mail]

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

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

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

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

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

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

  [e-mail]

  customer/department=[e-mail]

  $[e-mail]

  !def![e-mail]

  [e-mail]

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

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

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

Answer 7

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

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

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

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

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

Answer 8

Название:

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

Сервер:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

Answer 9

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

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

Answer 10

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

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

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

Answer 11

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

Выдержка:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=[e-mail]
\$[e-mail]
!def![e-mail]
[e-mail]

Answer 12

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

Очевидно, что ответ на вопрос не так прост, как его задавали. Предлагаемые стандарты, когда дело доходит до именования имени почтового ящика, если быть точным, <user-name> в этом контексте, наряду с интерпретациями этих RFC, далеко и многочисленны.

Что касается части <user-name>, то Руководящая группа по универсальному принятию опубликовала подробное руководство относительно того, что представляет собой локальная часть идентификатора электронной почты, в документе под названием UASG-028 здесь.

Для части <server> все символы, упомянутые в настоящем документе « Кодовые точки Unicode и интернационализированные доменные имена для приложений (IDNA) », со статусом символа «PVALID». Кроме того, символы со статусом "CONTEXTJ" и "CONTEXTO" допустимы в определенных контекстных условиях.

Answer 13

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

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

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

• цифры 0 в 9;

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

• точка . при условии, что он не является первым или последним символом, если он не указан в кавычках, а также при условии, что он не появляется последовательно, если он не указан (например, [e-mail] не допускается, но "John..Doe"@example.com позволено);

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

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

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

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

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

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

Answer 14

Ответ (почти) 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 ....

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

Answer 15

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

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

Answer 16

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

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

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

Answer 17

В моем 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'[e-mail]"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

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

Answer 18

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

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

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

    local part starts with a period ( [e-mail] )
    local part ends with a period   ( [e-mail] )
    two or more periods in series   ( [e-mail] )
    &’`*|/                          ( some&thing`[e-mail] )
    more than one @                 ( which@[e-mail] )
    :%                              ( mo:characters%mo:[e-mail] )

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

John.."The*$hizzle*Bizzle"[e-mail] --> [e-mail]

[e-mail] --> [e-mail]

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

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

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

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

Answer 19

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