Які символи дозволено в електронній адресі?

Я не запитую про повну перевірку електронної пошти.

Я просто хочу знати, які дозволені символи 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)". Я знаю, що люди в США та A часто не займаються цим, але це вже широко розповсюджене та швидко зростаюче використання у всьому світі (головним чином, в яких переважають англійські).

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

Сам я мало знав про цю розробку, поки не повернувся до Японії і не почав бачити такі адреси електронної пошти, як hei @ や and .ca та URL-адреси Amazon, як це:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ス - デ ジ タ ル メ ラ - ポ ー タ ブ ル ー デ ィ / b / ref = topnav_storetab_e? ie = UTF8 & node = 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 (надіслано з 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(подвійна крапка після @)
• дійсна адреса з провідним пробілом
• дійсна адреса з пробілом

Джерело: Адреса електронної пошти у Вікіпедії

Реггекс RFC2822 Perl для перевірки електронних листів:

(?:(?:\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,7 к.

Дивіться також: Аналізатор адрес електронної пошти 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 також попереджає, що "хост, який розраховує на отримання пошти, ДОБРЕ уникнути визначення поштових скриньок, де Локальна частина вимагає (або використовує) формуляризованих рядків".

Google робить цікаву справу зі своїми адресами gmail.com. Адреси gmail.com дозволяють використовувати лише літери (az), цифри та періоди (які ігноруються).

наприклад, pikachu@gmail.com - це те саме, що і pi.kachu@gmail.com, і обидві адреси електронної пошти будуть надіслані на одну і ту ж поштову скриньку. PIKACHU@gmail.com також доставляється на ту саму поштову скриньку.

Отже, щоб відповісти на питання, іноді від виконавця залежить, яку частину стандартів RFC вони хочуть дотримуватися. Стиль адреси gmail.com Google сумісний із стандартами. Вони роблять це так, щоб уникнути плутанини, коли різні люди брали б подібні адреси електронної пошти, наприклад

*** 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 символ, окрім знаку at ("@"), зворотній кут, подвійний цитат, кома або квадратні дужки може з’являтися без цитування. Якщо має бути якийсь із цього списку виключених символів, вони повинні бути цитованими. Такі форми, як

  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 також попереджає, що "хост, який розраховує на отримання пошти, ДОБРЕ уникнути визначення поштових скриньок, де Локальна частина вимагає (або використовує) формуляризованих рядків".

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

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

Відповідь (майже) 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". Багато контрольних символів також дозволено / використовувати. Один список таких контрольних функцій відображається на сторінці 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 ....

Тому таке правило включення є "просто занадто широким". Або, в іншому розумінні, очікуване правило є "занадто спрощеним".

Для простоти я санітую подання, видаливши весь текст із подвійних лапок і ті, що пов'язані з навколишніми подвійними цитатами перед валідацією, поставивши кібош на подання електронної пошти на підставі того, що заборонено. Просто тому, що хтось може мати Джона. "* $ Hizzle * Bizzle" .. Адреса Doe@wever.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 із спеціальними символами.